diff --git a/pep-0451.txt b/pep-0451.txt
index 399902806..56c060a82 100644
--- a/pep-0451.txt
+++ b/pep-0451.txt
@@ -9,7 +9,7 @@ Type: Standards Track
 Content-Type: text/x-rst
 Created: 8-Aug-2013
 Python-Version: 3.4
-Post-History: 8-Aug-2013, 28-Aug-2013, 18-Sep-2013
+Post-History: 8-Aug-2013, 28-Aug-2013, 18-Sep-2013, 24-Sep-2013
 Resolution:
 
 
@@ -58,7 +58,7 @@ it can load, as well as about data from sources associated with such a
 module.
 
 Right now loaders (via load_module()) are responsible for certain
-boilerplate import-related operations.  These are:
+boilerplate, import-related operations.  These are:
 
 1. perform some (module-related) validation;
 2. create the module object;
@@ -76,7 +76,7 @@ origin
 This is a new term and concept.  The idea of it exists subtly in the
 import system already, but this proposal makes the concept explicit.
 
-"origin" is the import context means the system (or resource within a
+"origin" in an import context means the system (or resource within a
 system) from which a module originates.  For the purposes of this
 proposal, "origin" is also a string which identifies such a resource or
 system.  "origin" is applicable to all modules.
@@ -133,7 +133,8 @@ PEP 3147.  For this proposal, the relevant API for module caching is the
 ``__cache__`` attribute of modules and the cache_from_source() function
 in importlib.util.  Loaders are responsible for putting modules into the
 cache (and loading out of the cache).   Currently the cache is only used
-for compiled source modules.  However, this proposal explicitly allows
+for compiled source modules.  However, loaders may take advantage of
+the module cache for other kinds of modules.
 
 package
 -------
@@ -141,7 +142,7 @@ package
 The concept does not change, nor does the term.  However, the
 distinction between modules and packages is mostly superficial.
 Packages *are* modules.  They simply have a ``__path__`` attribute and
-import may add attributes bound to submodules.  The typical perceived
+import may add attributes bound to submodules.  The typically perceived
 difference is a source of confusion.  This proposal explicitly
 de-emphasizes the distinction between packages and modules where it
 makes sense to do so.
@@ -273,12 +274,6 @@ finders.  See the `Factory Functions`_ section below for more detail.
 * from_loader(name, loader, \*, origin=None, is_package=None) - build
   a spec with missing information filled in by using loader APIs.
 
-This factory function is useful for some backward-compatibility
-situations:
-
-* spec_from_module(module, loader=None) - build a spec based on the
-  import-related attributes of an existing module.
-
 Other API Additions
 -------------------
 
@@ -332,10 +327,12 @@ Other Changes
 * The import system implementation in importlib will be changed to make
   use of ModuleSpec.
 * importlib.reload() will make use of ModuleSpec.
-* Import-related module attributes (other than ``__spec__``) will no
-  longer be used directly by the import system.
+* A module's import-related attributes (other than ``__spec__``) will no
+  longer be used directly by the import system during that module's
+  import.  However, this does not impact use of those attributes
+  (e.g. ``__path__``) when loading other modules (e.g. submodules).
 * Import-related attributes should no longer be added to modules
-  directly.
+  directly, except by the import system.
 * The module type's ``__repr__()`` will be a thin wrapper around a pure
   Python implementation which will leverage ModuleSpec.
 * The spec for the ``__main__`` module will reflect the appropriate
@@ -459,8 +456,11 @@ functionality::
        sys.modues[spec.name] = module
        try:
            spec.loader.exec_module(module)
-       except Exception:
-           del sys.modules[spec.name]
+       except BaseException:
+           try:
+               del sys.modules[spec.name]
+           except KeyError:
+               pass
            raise
        return sys.modules[spec.name]
 
@@ -599,17 +599,6 @@ related module attributes.  See the table in `Attributes`_.
 Omitted Attributes and Methods
 ------------------------------
 
-The following ModuleSpec methods are not part of the public API since
-it is easy to use them incorrectly and only the import system really
-needs them (i.e. they would be an attractive nuisance).
-
-* _create() - provide a new module to use for loading.
-* _exec(module) - execute the spec into a module namespace.
-* _load() - prepare a module and execute it in a protected way.
-* _reload(module) - re-execute a module in a protected way.
-
-Here are other omissions:
-
 There is no "PathModuleSpec" subclass of ModuleSpec that separates out
 has_location, cached, and submodule_search_locations.  While that might
 make the separation cleaner, module objects don't have that distinction.