besides the cost of closing the door to relaxed annotation syntax, there's the engineering work of undoing the work that was done to make `from __future__ import annotations` the default (doing this was a significant effort spread over many commits, and undoing will be just as hard).
I'm not sure either of those statements is true.
Accepting PEP 649 as written would deprecate stringized
annotations, it's true. But the SC can make any decision it wants
here, including only accepting the new semantics of 649 without
deprecating stringized annotations. They could remain in the
language for another release (or two? or three?) while we "kick
the can down the road". This is not without its costs too but it
might be the best approach for now.
As for undoing the effort to make stringized annotations the
default, git should do most of the heavy lifting here. There's a
technique where you check out the revision that made the change,
generate a reverse patch, apply it, and check that in. This
creates a new head which you then merge. That's what I did when I
created my co_annotations branch, and at the time it was literally
the work of ten minutes. I gather the list of changes is more
substantial now, so this would have to be done multiple times, and
it may be more involved. Still, if PEP 649 is accepted, I would
happily volunteer to undertake this part of the workload.
Cheers,
/arry