Apply suggestions from code review

Co-authored-by: Carol Willing <carolcode@willingconsulting.com>

Author: mgorny

peps/pep-0825.rst

@@ -26,7 +26,9 @@ This PEP provides the data format for variant wheels, an extension to
 :doc:`packaging:specifications/binary-distribution-format` that permits
 building multiple variants of the same package while embedding
 additional compatibility data. This data is stored inside the wheel, and
-expressed via a human-readable variant label in the filename. When
+expressed via a human-readable variant label in the filename.
+
+When
 wheels are hosted on an index, it is additionally exposed in a separate
 JSON file as an optimization. It will be followed by additional PEPs
 defining the remaining aspects of variant wheels. The final aim of the
@@ -83,9 +85,9 @@ Tools that produce the data formats according to this specification
 (variant wheels, the index-level metadata file) MUST always produce
 files that meet the requirements of this specification.
 
-Tools that consume the data formats according to this specification are
-not required to verify that the data meets these requirements, but
-SHOULD NOT rely on data that they have established does not meet them.
+Tools that consume this specification's data formats are
+not required to verify that the data meets these requirements. A tool
+SHOULD NOT rely on data that the tool has established does not meet the specification format.
 The appropriate response depends on the role of the tool, and follows
 the same pattern as for invalid Core Metadata in wheel files. Tools that
 are in a position to reject invalid data at the point it enters the
@@ -523,7 +525,7 @@ example by specifying a preference for specific namespaces, features
 or properties. The tools MAY also provide options to exclude specific
 variants, or to select a particular variant. These options operate on
 the wheels that were found compatible, so they MAY reorder or narrow
-that set, but MUST NOT cause a wheel to be selected whose properties
+that set, but MUST NOT cause selection of a wheel with properties
 the target system does not support. Installing a variant wheel for a
 system other than the one being installed to is instead a matter of
 overriding which properties are considered supported, which is `out of
@@ -731,7 +733,7 @@ operators permitted with each of them:
     # equivalent
     dep7; "foo::bar::baz" in variant_properties
 
-The filtering in step 3. is only observable where a variant feature
+The filtering in step 3 is only observable where a variant feature
 lists multiple values, of which the target system needs to support just
 one (see `variant properties`_). Consider a wheel whose properties
 include both of:
@@ -1059,9 +1061,9 @@ Installing wheels from multiple sources (non-normative)
 
 As of the time of writing, there are no accepted standards addressing
 the support for installing packages from multiple sources, and the
-existing tools (such as ``pip`` and ``uv``) disagree on the exact
+existing tools differ on the exact
 behavior. This problem is described in more detail in the informational
-:pep:`766`. Variant wheels expand the problem scope. The consistency
+:pep:`766`. Variant wheels extend these differences. The consistency
 requirements that make variant metadata combinable hold within a single
 project, and nothing obliges independent publishers to meet them with
 respect to one another: the same variant label may map to different
@@ -1071,7 +1073,7 @@ sources happens to be combinable is possible, but the cost of doing so
 in the general case is prohibitive, and there is no correct answer when
 it is not. For these reasons, the specification does not attempt to
 standardize a behavior, but instead considers it implementation-defined
-and provides a few non-normative suggestions on the possible solutions.
+and provides a few non-normative, suggested solutions, including using non-variant wheel.
 
 It is entirely valid for tools not to support this behavior, either by
 not providing support for using multiple sources at all, or by rejecting