Add mention that indirection entries in sys.modules will not be supported once

absolute/relative imports are the only import semantics supported.
Specifically mention that this will definitely happen for Python 3.0.

pep-0328.txt

@@ -278,6 +278,26 @@ module, regardless of where the module is actually located on the file
 system.
 
 
+Relative Imports and Indirection Entries in sys.modules
+=======================================================
+
+When packages were introduced, the concept of an indirection entry in
+sys.modules came into existence [2]_.  When an entry in sys.modules
+for a module within a package had a value of None, it represented that
+the module actually referenced the top-level module.  For instance,
+'Sound.Effects.string' might have a value of None in sys.modules.
+That meant any import that resolved to that name actually was to
+import the top-level 'string' module.
+
+This introduced an optimization for when a relative import was meant
+to resolve to an absolute import.  But since this PEP makes a very
+clear delineation between absolute and relative imports, this
+optimization is no longer needed.  When absolute/relative imports
+become the only import semantics available then indirection entries in
+sys.modules will no longer be supported.
+
+
+
 References
 ==========
 
@@ -297,6 +317,8 @@ For more background, see the following python-dev threads:
 
 .. [1] http://mail.python.org/pipermail/python-dev/2004-March/043739.html
 
+.. [2] http://www.python.org/doc/essays/packages.html
+
 
 Copyright
 =========

pep-3100.txt

@@ -83,8 +83,10 @@ Core language
   where floats are inadvertantly accepted (PyArg_ParseTuple() i & l formats)
 * Remove from ... import * at function scope.  This means that functions
   can always be optimized and support for unoptimized functions can go away.
-* Imports will be absolute by default. [done]
-  Relative imports must be explicitly specified [#pep328]_ [done]
+* Imports [#pep328]_
+    + Imports will be absolute by default. [done]
+    + Relative imports must be explicitly specified. [done]
+    + Indirection entires in sys.modules will not be supported.
 * __init__.py might become optional in sub-packages.  __init__.py will still
   be required for top-level packages.
 * Cleanup the Py_InitModule() variants {,3,4} (also import and parser APIs)