diff --git a/peps/pep-0825.rst b/peps/pep-0825.rst
index a82475390ef..a1ec9df172d 100644
--- a/peps/pep-0825.rst
+++ b/peps/pep-0825.rst
@@ -313,12 +313,12 @@ the Binary Distribution Format specification.
 The exact URL where the file is hosted is insignificant, but it MUST
 be provided in all the responses where the variant wheels are included.
 It should follow the rules for files in the
-:ref:`packaging:simple-repository-api`, except that the various metadata
-served by the index (such as ``core-metadata``, ``dist-info-metadata``,
-``requires-python`` or ``yanked``) are not meaningful for that file.
-Indexes MAY publish or skip these attributes, as long as the values do
-not prevent correct operation. Tools MAY either use or ignore these
-values.
+:ref:`packaging:simple-repository-api`, except that the optional
+metadata attributes served by the index (such as ``core-metadata``,
+``dist-info-metadata``, ``requires-python`` or ``yanked``) are not
+meaningful for that file. Indexes MAY publish or skip these attributes,
+as long as the values do not prevent correct operation. Tools MAY either
+use or ignore these values.
 
 This file uses the same structure as `variant metadata`_, except that
 the ``variants`` object MUST list all variants available on the package
@@ -876,17 +876,17 @@ incidental platform tag difference.
 While a future PEP will define how variant properties are provided, a
 baseline assumption is made that the compatible properties will be
 provided in specific order corresponding to their preference. This makes
-it possible to use a generic sorting algorithm that, and later define
+it possible to use a generic sorting algorithm, and later define
 properties as data without having to change the algorithm.
 
 A future PEP will define how the ordering for features and values is
 provided. However, namespaces are governed independently and considered
 on equal footing, and therefore there will be no standard ordering for
-them. Instead, the package maintainer will decide which namespaces have
-higher priority, and therefore which variants will be preferred. For
-completeness, the specification also permits the maintainers to override
-the ordering for features and values as well. Tools can also further
-override the variant choice, much like they can do with regular wheels.
+them. Instead, the ordering of namespaces will be explicitly stated in
+the variants metadata, which in turn will be provided by the package
+maintainer as part of the build process. For completeness, it will also
+be possible to provide overrides for the ordering of features and values
+via the same mechanism.
 
 In the vast majority of real use cases, ordering based on properties
 will suffice. However, in a pathological case two different variant
@@ -1070,7 +1070,8 @@ The following problems are deferred to subsequent PEPs in the series:
 - determining which variant properties are compatible with the system
 - building variant wheels
 
-In addition to that, the following questions are left undefined:
+In addition to that, the following matters are left
+implementation-defined:
 
 - Selecting variant wheels from multiple sources. Currently, there is no
   standard defined behavior for regular wheels, nor consensus across