Apply more suggestions from code review

Co-authored-by: Alyssa Coghlan <ncoghlan@gmail.com>

Author: mgorny

source/discussions/downstream-packaging.rst

@@ -165,9 +165,11 @@ should ideally extend to these processes as well.
 Support building against system dependencies
 --------------------------------------------
 
+
 Why?
 ~~~~
 
+
 Some Python projects have non-Python dependencies, such as libraries written
 in C or C++. Trying to use the system versions of these dependencies
 in upstream packaging may cause a number of problems for end users:
@@ -202,6 +204,10 @@ However, none of these issues apply to downstream packaging, and downstreams
 have good reasons to prefer dynamically linking to system dependencies.
 In particular:
 
+- in many cases, reliably sharing dynamic dependencies between components is a large part
+  of the *purpose* of a downstream packaging ecosystem. Helping to support that makes it
+  easier for users of those systems to access upstream projects in their preferred format.
+
 - in many cases, reliably sharing dynamic dependencies between components is a large part
   of the *purpose* of a downstream packaging ecosystem. Helping to support that makes it
   easier for users of those systems to access upstream projects in their preferred format.
@@ -231,6 +237,7 @@ In particular:
 How?
 ~~~~
 
+
 A good compromise between the needs of both parties is to provide a switch
 between using vendored and system dependencies. Ideally, if the package has
 multiple vendored dependencies, it should provide both individual switches
@@ -243,6 +250,11 @@ message rather than fall back to a vendored version. This gives the packager
 the opportunity to notice their mistake and a chance to consciously decide
 how to solve it.
 
+Note that it is reasonable for upstream projects to leave *testing* of building with
+system dependencies to their downstream repackagers. The goal of these guidelines
+is to facilitate more effective collaboration between upstream projects and downstream
+repackagers, not to suggest upstream projects take on tasks that downstream repackagers
+are better equipped to handle.
 Note that it is reasonable for upstream projects to leave *testing* of building with
 system dependencies to their downstream repackagers. The goal of these guidelines
 is to facilitate more effective collaboration between upstream projects and downstream
@@ -254,9 +266,11 @@ are better equipped to handle.
 Support downstream testing
 --------------------------
 
+
 Why?
 ~~~~
 
+
 A variety of downstream projects run some degree of testing on the packaged
 Python projects. Depending on the particular case, this can range from minimal
 smoke testing to comprehensive runs of the complete test suite. There can
@@ -291,6 +305,7 @@ that they report**.
 How?
 ~~~~
 
+
 There are a number of things that upstream projects can do to help downstream
 repackagers test their packages efficiently and effectively, including some of the suggestions
 already mentioned above. These are typically improvements that make the test suite more