Diff frommypy_primer, showing the effect of this PR on open source code:

pydantic (https://github.com/pydantic/pydantic)- pydantic/v1/typing.py:47: error: Incompatible types in assignment (expression has type "tuple[()]", variable has type "type[GenericAlias]")  [assignment]+ pydantic/v1/typing.py:47: error: Incompatible types in assignment (expression has type "tuple[()]", variable has type "type[GenericAlias[_OriginT_co]]")  [assignment]discord.py (https://github.com/Rapptz/discord.py)- discord/ext/commands/converter.py:1119: error: Return type "Greedy[T]" of "__class_getitem__" incompatible with return type "GenericAlias" in supertype "list"  [override]+ discord/ext/commands/converter.py:1119: error: Return type "Greedy[T]" of "__class_getitem__" incompatible with return type "GenericAlias[type | TypeAliasType]" in supertype "list"  [override]

What problem does this solve? The class is not generic at runtime and I think pretending it is is likely to cause more confusion than it's worth.

What problem does this solve?

It makes it possible to annotatetyping.get_origin:

Runtime-typing libraries that only accept subscripted types could also benefit from this: If e.g.x=list[int] is allowed butx=list isn't, they are now able to enforce this by annotatingx: GenericAlias[list[Any]] (assuming static type-checker support). If I remember correctly,pydantic requires this is some places, raising a runtime error otherwise.

The class is not generic at runtime and I think pretending it is is likely to cause more confusion than it's worth.

I suppose that's a bit of a chicken/egg story. And in my experience, typeshed usually takes the lead in these kinds of things, and cpython then follows (e.g.#13760).
Also note thatGenericAlias is likely only used by people with thorough knowledge about typing in Python. So I don't expect them to become confused by it beingoptionally generic.