Of course they're not fleeing, the vast majority of them are just users and so have no influence over how those features are implemented. The alternative to not using attributes for Unity is... not using Unity (or at least not using it in a supported manner). But those runtime attributes are a huge drain on Unity's runtime performance, and like all attributes, lead to poor developer experience.
I don't see how this would change. Similar to @davedelong's example, you would just express the key difference with a different attribute. Your example is also pretty poor given Codable
has many long standing UX issues that could just be fixed rather than needing a whole runtime system to make usable. It seems like your problem could be solved by improvements to Codable, improvements to property wrappers, or another compile time feature. It doesn't seem like this problem needs runtime involvement at all.
This doesn't really make sense to me. If you insist on having all of the metadata exposed, which is not a given, you can do so in a structured way at compile time. There's nothing requiring compile time constructs to be as awkward as Codable.
And in fact, composition issues can be mitigated by moving metadata around, since it then becomes possible to define away the sharp edges of the composition in the first place. Besides which, I was asking how the pitch's actual feature composes with other actual Swift features, which is important to define, so it wasn't a general question with a general answer. There is also the question of how these things interact at runtime, but that's a problem for attribute implementors, as there's little a general runtime system can do to limit those issues.
Would there be a way to see the backing storage? Is visibility impacted by the order of attributes? It seems like people would want to change behavior based on whether a property is wrapped by another type.