Minor wording for package distributions

Author: astrofrog

peps/pep-0771.rst

@@ -859,7 +859,8 @@ in the dependency section, e.g.:
 
 This idea may seem appealing because it is technically already feasible. However, in
 practice, many projects have opted not to do this, for a number of reasons, which
-we now take a look at.
+we now take a look at. Some of these may not be applicable to future new projects,
+but some of them apply to all projects, old and new.
 
 Mismatch between package and module name
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -956,10 +957,8 @@ Package distributions
 
 Having two packages instead of one would increase the long-term maintenance cost
 of package distributions simply by virtue of the fact that two packages would
-have to be released instead of one. To take the example of conda-forge, two
-repositories would now be required, and the version pinning would need to be
-updated manually every time. The metapackage could only be built once the core
-package had been built and published, which would lengthen the release process.
+have to be released instead of one, and in some cases this would introduce extra
+manual work at each release.
 
 Synchronizing metadata
 ^^^^^^^^^^^^^^^^^^^^^^
@@ -985,8 +984,8 @@ Overall, this solution would imply a significantly higher maintenance burden,
 not just in terms of initial set-up and transition (which could already be
 prohibitive for large established projects), but also in terms of long-term
 maintenance. This also has the potential for breaking user workflows (in
-particular around the issue of repositories, and e.g. uninstallation), so for
-this reason we do not consider it a compelling alternative to the present PEP.
+particular around the issue of repositories, and e.g. uninstallation). For all
+these reasons, we do not consider it a compelling alternative to the present PEP.
 
 Syntax for deselecting extras
 -----------------------------