Rather than modelling @noncopyable as a modifier for the type, I still feel the clearer model is to think of it as a compiler directive to suppress the implicit Copyable conformance that is currently applied to all types.
Lots of things fall cleanly out if you have a way to suppress an implicit Copyable conformance for a scope (whether it be type scope, a section of a file, file scope, or module scope). It naturally composes with implicit Reflectable or Sendable; it’s describable with existing terminology (“this type isn’t Copyable); it doesn’t require inventing new generic syntax (a generic function that requires copyability would have an explicit or implicit T: Copyable constraint); and it easily extends to having an API- or ABI-stable module enforce that the author is explicit about which types are Copyable to avoid source or ABI breaks (for example, I’d imagine most of the standard library would eventually be compiled with implicit copyability disabled).
To allow for progressive disclosure, the assume-Copyable scopes would also implicitly add a T: Copyable constraint to any generic functions within that scope. Since everything is currently implicitly within an assume-Copyable scope, this means that code continues to compile as it does today unless the user explicitly opts out.