Yes. The scope of the proposal is well-defined and a change to the syntax was intentionally put in the Future Directions section, because it needs its own pitch and proposal where we can have a more in-depth discussion about other accessors and implicit arguments. This proposal is purely about semantics and changes to the syntax are clearly out of scope.
I don't know when the Core Team plans to run a review for this, but if at the end of the review they decide that we must make the deprecation now, then I can update the implementation to do so (it would only requires a few trivial changes). However, it's not something that I am officially proposing, so I would leave the decision to them. If someone wants to discuss the syntax changes further (and take it forward) then I encourage them to create a new pitch thread.
I'm generally not in favor of anything that makes me do more work than what I'm already used to doing. However, in the case of oldValue in didSet or error in catch, when I was new to Swift, it was very counterintuitive that these magic variables would just appear in some cases.
Similarly, the $0 and $1 in closures made me ask, "what the heck is this, some shell script?". Even now, they seem ugly and out-of-place in Swift, a language that ostensibly prefers clarify over brevity. If we can reference parameters by number in a closure, why not in a regular function?
Considering the goal of the Swift 5.2 release is "significant quality and performance enhancements", it would be great to see this being scheduled for review!
@John_McCall Has the core team discussed this proposal? Is there anything the core team wants me to add/remove to the proposal and/or implementation before it goes into review? I would really appreciate some feedback. Thank you!