Hi Paul,
The runtime component is the API provided by the `typing` module such as `get_type_hints()`, plus the `__annotations__` attribute on various objects (classes and functions, mostly).
I am not aware of any plans or proposals to remove `__annotations__` or `typing.get_type_hints()`, and obviously use cases like yours abound.
That said, the needs of static checking (e.g. mypy) and runtime checking (e.g. JSON schema checkers) sometimes diverge, and in those cases I tend to favor the needs of static checkers.
PEP 563 is an example: we found that developers were having a hard time with the original requirement that all annotations are evaluated as expressions at the time the function definition is executed, since it makes forward references difficult (requiring the hack of enclosing the annotation in string quotes).
At the same time we found that static type checks are much more used than runtime type checks -- presumably for performance reasons. So PEP 563 was born -- annotations containing forward references no longer need to be quoted, making the use of static checkers simpler, while still catering to the needs of runtime checkers via typing.get_type_hints(). (Note that the latter was already needed to deal with explicitly quoted forward references pre-PEP-563.)
It is not inconceivable that eventually type system features will be introduced that are hard to check at runtime, and in such cases we will not let that stop us from defining the new type system feature. (I already doubt that there are runtime checkers that check the consistent use of type variables at runtime.)
That said, I don't see a reason to start deprecating the runtime introspection features of the existing annotation syntax, and if you look at PEP 585 (`list[int]` etc.) or PEP 604 (`int | str` union notation) you'll see that they are completely runtime introspectable. (Believe me, it would have been much simpler to erase type parameters completely at runtime, but I personally wrote most of the implementation to make them available via attributes on the `types.GenericAlias` type.)
Hope this helps,
--Guido