Everything deprecated would become ill-formed in the future, or would
have its meaning altered by a future proposal that claims the syntax.
[...]
I also want to keep what will become of the syntax intentionally
vague, since we don't know whether it will be removed or reclaimed.
All the developer needs to know is what is getting deprecated.
As a working programmer, I think the difference between
- "We're deprecating this, in order to make it ill-formed in the future (your vendor will likely support it indefinitely with a warning)"
- "We're deprecating this, in order to alter its meaning in the future (you must move off it or risk your code silently breaking later)"
is highly significant. Your proposal is mixing both kinds of change in the same paper — which is 100% fine IMHO, but I'd like a nice clear table of which of your changes fall into which bucket, so that the reader can be informed.
This is significant for programmers, but also significant for compiler vendors, too, because they're the ones who will have to craft the wording of their compiler diagnostics for those two distinct cases.
–Arthur