To expand on this point, the -X lazy_imports="disabled" option is in direct contradiction with the motivation of using lazy import to avoid using if TYPE_CHECKING for circular type checking references.
If the response is simply to say “don’t use lazy imports for circular type references,” I foresee that will lead to frustration on both sides. Library authors will (perhaps unintentionally) create circular references, only to later get bug reports from those (presumably) rare users that disable lazy imports.
This is manageable so long as Python 3.14 is supported (since a non-lazy code path is still required), but will cause problems once libraries stop supporting 3.14 and expect lazy imports to work reliably. More generally, lazy circular imports (typing or otherwise) are likely to become relatively common in a few years, at which time the -X lazy_imports="disabled" option will be effectively unusable (since even a single such use in any library will break).
The PEP discusses how lazy imports become potentially lazy during evaluation. Have the PEP authors contemplated an analogous potentially eager state that eagerly reifies lazy imports except for those which reference partially imported modules?