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