This is fantastic. The revision not only addresses prior concerns in an elegant way, the text is extremely well written. This proposals adds a powerful new capability to property wrappers in an elegant way that fits with the existing feel and direction of Swift. I haven't used other languages with similar features (does Kotlin have something like this?). I've followed all prior iterations and read this proposal again carefully.
One specific point of clarification. In the text it says, under "Detailed design":
API property wrapper attributes can only be applied to parameters in overridden functions or protocol witnesses if the superclass function or protocol requirement, respectively, has the same property wrapper attributes [emphasis added].
Rationale : This restriction ensures that the call-site transformation is always the same for families of dynamically dispatched functions.
It later says, under "Future directions":
API property wrappers in protocol requirements
Protocol requirements that include property wrappers was pitcheda while ago, but there was a lot of disagreement about whether property wrappers are implementation detail or API. With this distinction formalized, we could allow only API-level property wrappers in protocol requirements.
So...is the use of property wrappers in protocol requirements part of the detailed design of this proposal, or a future direction that isn't part of this proposal? (I would very much love for it to be the former, but totally understand that the work has to stop somewhere if it's to ship.)