Just to bring in some context for this discussion: https://github.com/python/cpython/pull/28279

We have dicussed in the PR above that current implementation depends on existing of `__future__` import of `annotations`.

With `from __future__ import annotations`:
1. Top level class var will be raise `TypeError`
2. Final and ClassVar function arguments will raise `TypeError`
3. Annotations like `x: 1` will raise `TypeError: Forward references must evaluate to types. Got 1.`

Without `from __future import annotations`it accepts all the cases above.

I share two opposite views on this change:
1. By adding the same `_type_check` logic we can reduce the inconsitency between two versions. It would be easier for users to migrate from one version to another.
2. By adding this feature, we would more aggresively force some specific semantics for builtin types. Which can possibly be problematic, for example I've tried to add `Final` annotations to function arguments in my own type checker. It is something current semantics does not support. Moreover, it can cause incompatibility to existing users.

My opinion is that consitency is more important here. Because I received quite a lot of bug reports from users involving different behavior with / without `__future__` import of `annotations`.

But, I understand that it is not up to me to decide :)