diff --git a/peps/pep-0773.rst b/peps/pep-0773.rst
index bb29f23edbc..f37da03e028 100644
--- a/peps/pep-0773.rst
+++ b/peps/pep-0773.rst
@@ -1099,6 +1099,13 @@ almost equivalent packages from NuGet (the latter does not include Tcl/Tk,
 making them significantly incompatible for some users, but this is likely okay
 for especially old versions).
 
+As of this PEP's acceptance, the plan is to create packages for all versions of
+Python 3.10.0 onwards (including patch releases, but excluding pre-releases), so that all non-EOL releases can
+be fully installed using PyManager. Versions from Python 3.5.0 onwards (excluding
+pre-releases) will directly reference the packages on NuGet, making them easily
+available in reduced form. Neither approach requires rebuilding the existing
+releases, nor are any changes required to the sources of those releases.
+
 
 Administrator installs
 ----------------------
@@ -1149,6 +1156,41 @@ substitution of 64-bit binaries. As PyManager runs as a standalone executable,
 this is not a necessary feature for the manager.
 
 
+Test suite and debug symbols
+----------------------------
+
+The existing installer optionally allows installation of the Python standard
+library test suite, and optional installation of debug symbols. Neither of these
+are necessary for most users, but they are convenient for some. Preliminary
+testing shows that omitting the test suite and debug symbols saves about 60% of
+the size of the compressed package (from 46MB to 18MB).
+
+The "default" CPython packages installed by PyManager will therefore not include
+the test suite or the debug symbols. However, there will be a second set of
+packages that do include these extras, grouped under ``PythonTest`` (as opposed
+to the default, ``PythonCore``). For example, where ``py install 3.13`` would
+install the default, ``py install PythonTest\\3.13`` would install a second
+runtime with the additional files (which can either be launched with ``py
+-V:PythonTest\\3.13``, or simply ``py -V:3.13`` if no equivalent ``PythonCore``
+version is installed).
+
+Debug binaries are no longer distributed, and all other optional features are
+included by default.
+
+
+Global pip command
+------------------
+
+Unlike the current Windows Store install, no global ``pip`` command is included
+(the traditional installer also does not include a global ``pip`` command,
+unless the options to modify ``PATH`` and to install pip are selected; the first
+of these is off by default). This impacts global installation of packages, which
+is already discouraged, but has no impact on activated virtual environments.
+
+The existing recommendation remains, which is to run ``python -m pip`` or
+``py -V:<TAG> -m pip`` to launch pip.
+
+
 Security Implications
 =====================
 
@@ -1672,47 +1714,6 @@ We could also detect the metadata and warn if the selected runtime does not
 match its requirement, but this is not part of the initial proposal.
 
 
-Open Issues
-===========
-
-Generate packages for old versions
-----------------------------------
-
-At present, we can install versions of Python back to 3.5 from the NuGet feed.
-These are identical to the traditional installer releases of the same versions,
-but do not include Tkinter, IDLE, documentation, or the test suite. However, it
-is very little work (and no additional storage space) to use them for older
-releases.
-
-New binaries releases will generate new packages, even for already released
-versions (currently 3.12 and 3.13). So these will exist. The open issue is
-whether we go back through old releases and generate full PyManager packages for
-them all, and how far back to go. This is merely repackaging, and does not
-require rebuilding or modifying the release.
-
-
-Include test suite in PyManager packages
-----------------------------------------
-
-The test suite consumes the majority of the size of our current distribution,
-but is not intended to be used by most of our users. By omitting it from the
-standard PyManager package, all downloads become smaller and faster, at the cost
-of some users having to obtain the test suite in another way (such as building
-from source).
-
-It seems obviously preferable to have some way to access the exact test suite
-intended for a particular build. So the question is whether to include it by
-default (there are no optional components anymore), to publish it independently
-(for manual download as a ZIP file), or to publish a second feed of packages
-that include both the runtime and the test suite.
-
-
-Footnotes
-=========
-
-TODO: Collate references
-
-
 Copyright
 =========