Even if the SC haven’t been formally asked for approval yet, I assume they’ll still keep an eye on how things are going, and chime in if they have specific concerns. It’s also an area where “seems like a good idea in principle” may fail in practice once stdlib modules like dataclasses actually attempt to adapt to the changes, so I think it makes sense to ask the SC for ratification of details that have already been demonstrated to work rather than asking for approval for everything that is being tried along the way.
On PEP 749 itself, I don’t think the current notes for wrapper functions are quite right, as they won’t do the right thing when __annotations__ has already been populated on the wrapped function.
I previously posted some thoughts on how to handle that to `functools.update_wrapper` will require changes for PEP 649 compatibility · Issue #21 · larryhastings/co_annotations · GitHub and I still believe that adding a suitable __annotate__ implementation to the wrapper object is the better approach.
The introduction of the annotations module also avoids the circular dependency I mentioned in that issue (inspect depends on functools, so functools depending on an inspect.get_annotations API would pose a problem beyond the mere fact of inspect being an expensive dependency)
The other thing I noticed was that the “stringizer” used to make the SOURCE format reconstruction possible was being kept private.
While splitting that functionality out from ForwardRef itself definitely makes sense, it seems like it might be a useful API to expose in its own right (potentially using a name like EvalToSourceRef or similar). I guess keeping it private initially doesn’t rule out making it public later, though.