Reword a few things to make it clear that switching to Python 3 as the default interpreter is still bleeding edge stuff at this point in time. Also clarify the Windows situation a little more.

pep-0394.txt

@@ -20,8 +20,8 @@ Python interpreter (i.e. the version invoked by the ``python`` command).
 
 * ``python2`` will refer to some version of Python 2.x
 * ``python3`` will refer to some version of Python 3.x
-* ``python`` will refer to the same target as either ``python2`` or
-  ``python3``, depending on the specific distribution and system
+* ``python`` *should* refer to the same target as ``python2`` but *may*
+  refer to ``python3`` on some bleeding edge distributions
 
 
 Recommendation
@@ -38,9 +38,8 @@ Recommendation
   any version of Python is installed and should invoke the same version of
   Python as either ``python2`` or ``python3``.
 * For the time being, it is recommended that ``python`` should refer to
-  ``python2``, except on distributions which include only ``python3`` in their
-  base install, or those that wish to push strongly for migration of user
-  scripts to Python 3.
+  ``python2`` (however, some distributions have already chosen otherwise; see
+  Notes below).
 * In order to tolerate differences across platforms, all new code that needs
   to invoke the Python interpreter should not specify ``python``, but rather
   should specify either ``python2`` or ``python3`` (or the more specific
@@ -69,24 +68,28 @@ This is needed as, even though the majority of distributions still alias the
 the former also do not provide a ``python2`` command; hence, there is
 currently no way for Python 2 code (or any code that invokes the Python 2
 interpreter directly rather than via ``sys.executable``) to reliably run on
-all systems without modification, as the ``python`` command will invoke the
-wrong interpreter version on some systems, and the ``python2`` command will
-fail completely on others. The recommendations in this PEP provide a very
-simple mechanism to restore cross-platform support, with minimal additional
-work required on the part of distribution maintainers.
+all Unix-like systems without modification, as the ``python`` command will
+invoke the wrong interpreter version on some systems, and the ``python2``
+command will fail completely on others. The recommendations in this PEP
+provide a very simple mechanism to restore cross-platform support, with
+minimal additional work required on the part of distribution maintainers.
 
 
 Notes
 =====
 
-* Distributions can alias the ``python`` command to whichever version of the
-  Python interpreter they choose (noting that, in the near term, most 3rd
-  party scripts will still expect this command to refer to Python 2.x). The
-  version chosen should also be available via either the ``python2`` or
-  ``python3`` command as appropriate.
+* Distributions that only include ``python3`` in their base install (i.e.
+  they do not provide ``python2`` by default) along with those that are
+  aggressively trying to reach that point (and are willing to break third
+  party scripts while attempting to get there) are already beginning to alias
+  the ``python`` command to ``python3``
+* More conservative distributions that are less willing to tolerate breakage
+  of third party scripts continue to alias it to ``python2``. Until the
+  conventions described in this PEP are more widely adopted, having ``python``
+  invoke ``python2`` will remain the recommended option.
 * The ``pythonX.X`` (e.g. ``python2.6``) commands exist on some systems, on
   which they invoke specific minor versions of the Python interpreter. It
-  would be wise for distribution-specific packages to take advantage of these
+  can be useful for distribution-specific packages to take advantage of these
   utilities if they exist, since it will prevent code breakage if the default
   minor version of a given major version is changed. However, scripts
   intending to be cross-platform should not rely on the presence of these
@@ -130,7 +133,10 @@ Backwards Compatibility
 A potential problem can arise if a script adhering to the
 ``python2``/``python3`` convention is executed on a system not supporting
 these commands. This is mostly a non-issue, since the sysadmin can simply
-create these symbolic links and avoid further problems.
+create these symbolic links and avoid further problems. It is a significantly
+more obvious breakage than the sometimes cryptic errors that can arise when
+attempting to execute a script containing Python 2 specific syntax with a
+Python 3 interpreter.
 
 
 Application to the CPython Reference Interpreter
@@ -171,10 +177,14 @@ between the different Python versions when the Start menu shortcuts are
 divorced from their containing folders (e.g. when they appear in the
 "Recently Used" list.
 
-While these are questions well worth addressing, they do not have easy
-answers. The authors of this particular PEP aren't even inclined to try to
-begin answering them, but anyone that wants to tackle them should feel free
-to start working on their own PEP :)
+While these questions are well worth addressing, they do not have easy
+answers. The authors of this particular PEP aren't inclined to even begin
+trying to answer them, but anyone that wants to tackle them should feel free
+to start working on their own PEP.
+
+Note that, while the topic has been excluded from this PEP, there is plenty of
+material in the linked python-dev discussion that may be useful in the design
+and implementation of a Windows-specific solution.
 
 
 References