I took a stab at a PR updating PEP 613, which gave me some thoughts.
My only remaining question is – why support type aliases inside function scopes? I don’t think there is meaningful value-add, and having to deal with a different type hierarchy based on scoping sounds like unnecessary complexity to me. Similarly with type aliases defined as instance variables, or anything beyond toplevel globals or class variables, which are essentially qualified globals.
Is there a technical reason to exclude them? Python in general has a philosophy that allows you to combine structures arbitrarily. We allow imports in functions. Why not type aliases?
In terms of spec complexity, I believe having different behavior for TypeAlias within functions vs classes vs global scope adds complexity to the spec (eg see scope-restrictions section of https://github.com/python/peps/pull/2154). It may be worth adding such spec-complexity in order to mitigate technical complexity - but I think such cases are rare. Usually spec simplicity is worth working for. If we allowed type aliases in functions, I think we could leave out the entire scope-restrictions section. I'm not familiar with the technical challenges of implementing type hierarchies - so I'll certainly defer to others here who work on type checkers. Per guido's point, this would be in line with python's general philosophy, but I'm also sympathetic to the point that type checking in python might want to be stricter than python's general philosophy. Is there some way to get the appropriate strictness while maintaining spec simplicity?