+0.9. Overall, I think this is a great feature. As-is, it will definitely add a lot of power and conciseness, especially for wrappers that are set-and-forget (you just apply them and then use the wrapped value from there on).
I echo others' concerns about the $ syntax being unintuitive. If it was not immediately obvious why a single $ accessed the wrapper value for some wrapped properties, it is really confusing what $$ means. I would much rather the verbosity of spelling it out as property, $property (the wrapper), and $property.binding (to use SwiftUI as an example). [EDIT] I am also receptive to the postfix $ idea mentioned previously. I do acknowledge that for the typical user of a wrapped property, this will probably not be as much of a problem -- they will read the documentation and probably fairly quickly accept the specialized meaning of one or two dollar signs in the context of the property wrapper they are using. Still, why add language features that make it unnecessarily harder (conceptually) to become the author of a new wrapper than it is to become a user of an existing one?
My only other concern with property wrappers is that they do not compose well with a Decodable conformance because property wrappers and Decodable conformance both rely on initializers. I don't think this concern is the burden of property wrappers alone and it certainly does not make me want the current feature as-designed to be rejected, but it is worth noting in case there is some future direction that has not been considered that could allow having a property wrapper both accept initial arguments and also define custom decoding rules. I think such a direction would require changes to how property wrappers are synthesized but hopefully not a drastic change to how they are written or any change to how they are used.
Lastly, I had a question that might lead to a bug report depending on whether the answer is "yes that is by design" or not. Is it intentional that the synthesized Decodable conformance of a type containing a wrapped property cannot allow for that property's key being omitted (as opposed to nullified)? This question is expounded upon here.
Yes, the surface area this feature covers is really large so it's a bit hard to even speak to the "problem it addresses" but even just the ability to wrap a property and still provide trivial and obvious access to the type being wrapped for free is a huge win.
Yes. There is not a proliferation of attributes in the language at the moment, but where they are used, this type of annotation that affects the behavior of the following thing feels at home.
N/A
I read the proposal and followed much of the discussion around the pitches. I have played with the current implementation a bit.