PEP 810: Clarify section on reification's semantics with the import machinery

peps/pep-0810.rst

@@ -363,17 +363,18 @@ Reification
 When a lazy object is first used, it needs to be reified. This means resolving
 the import at that point in the program and replacing the lazy object with the
 concrete one. Reification imports the module in the same way as it would have
-been if it had been imported eagerly, barring intervening changes to the
-import system (e.g. to ``sys.path``, ``sys.meta_path``, ``sys.path_hooks`` or
-``__import__``).
-
-Reification still calls ``__import__`` to resolve the import. When the module
-is first reified, it's removed from ``sys.lazy_modules`` (even if there are
-still other unreified lazy references to it). When a package is reified and
-submodules in the package were also previously lazily imported, those
-submodules are *not* automatically reified but they *are* added to the reified
-package's globals (unless the package already assigned something else to the
-name of the submodule).
+been if it had been imported eagerly. Notably, reification still calls
+``__import__`` to resolve the import, which uses the state of the import system
+(e.g. ``sys.path``, ``sys.meta_path``, ``sys.path_hooks`` and ``__import__``)
+at **reification** time, **not** the state when the ``lazy import`` statement
+was evaluated.
+
+When the module is first reified, it's removed from ``sys.lazy_modules`` (even
+if there are still other unreified lazy references to it). When a package is
+reified and submodules in the package were also previously lazily imported,
+those submodules are *not* automatically reified but they *are* added to the
+reified package's globals (unless the package already assigned something else
+to the name of the submodule).
 
 If reification fails (e.g., due to an ``ImportError``), the exception is
 enhanced with chaining to show both where the lazy import was defined and