> 1. By adding the same `_type_check` logic we can reduce the inconsistency between two versions. It would be easier for users to migrate from one version to another.

That's definitely a plus. But please consider this hypothetical scenario:

- Let's say some typing code has _type_check in 3.8
- In 3.12, we decide to give type hinting with ints (like `x: 1`) some meaning (this has been proposed before in typing-sig).
- The new construct arrives in 3.12. We backport to typing_extensions, which *must* support 3.8's typing module.
- Now the new addition to 3.12 typing_extensions doesn't work with 3.8 typing because of _type_check, and we need to hack around it.
- The hacks may eventually lead to real behavioral inconsistencies between typing_extensions and typing.

If this sounds familiar, that's because something similar has already happened! Callable and Generic had too strict checking in typing (requiring Callable's args to be a tuple of types always) before 3.10. So typing_extensions doesn't support the full PEP 612 syntax :( https://github.com/python/typing/tree/master/typing_extensions#other-notes-and-limitations.

Stricter runtime type checking makes growing the typing syntax harder. For the newer types, we try to defer checking to 3rd-party libraries.

> Because I received quite a lot of bug reports from users involving different behavior with / without `__future__` import of `annotations`.

Your perspective as a runtime typing library dev is very valuable. Thank you for your feedback! IMO, `from __future__ import annotations` becoming the default in 3.11 is still undecided. It was yanked from 3.10 for breaking pydantic and FastAPI, and I doubt it will land in 3.11 for the same reasons. It seems the current consensus is to use that import for code with purely static typing, and not use it with runtime typing libraries.