You’re running into a limitation that’s actually by design in Move. Even if your generic type T is constrained with key + store, the compiler still doesn’t know anything about the fields inside T. The key ability just ensures that T includes a UID, but it’s more of a type system rule, not a way for the compiler to infer structure. So T having an id field is not something you can rely on at compile time.

Also important: field access in Move is restricted to the module where the struct is defined. So even if T wasn’t generic, if it comes from another module, you still wouldn’t be able to access its fields directly.

What you’re trying to do — pass &mut my_obj.id from a generic object — isn’t possible, and that’s intentional. It protects key invariants in Move, especially around UID safety. Allowing generic mutable access to fields like UID would violate core security guarantees in the language.

If your goal is to use df::add, and you’re trying to attach a field to the object’s UID, you’ll need to restructure your code. One way is to bypass the generic entirely and write:

public fun add_df(uid: &mut UID, new_id: ID) {
    df::add(uid, b"aaa".to_string(), new_id);
}

This works if you can safely get access to the &mut UID, but that’s a sensitive operation — you should avoid exposing mutable references to UID unless you’re absolutely sure about the implications.

If your app only uses a few known struct types, another practical solution is to write separate logic per type, without using generics.

To dive deeper into how dynamic fields work and how to design around UID access, I highly recommend this chapter from the Move Book: https://move-book.com/programmability/dynamic-fields.html#dynamic-fields

There are two things you should know:

1. Fields can only be accessed in the module that defines the struct. So even without generic you wouldn't be able to access the fields for a foreign type.
2. I think I undestand where you're coming from: key forces id: UID field, but it's only an additional "verifier rule", and not a hint for compiler. In other words, compiler doesn't know that T has any fields, and is not supposed to know