wording of concerns/disadvantages

Author: adqm

peps/pep-0798.rst

@@ -709,8 +709,8 @@ were raised as well. This section aims to summarize those concerns.
   Expressions like ``f(*x for x in y)`` may initially appear ambiguous, as it's
   not obvious whether the intent is to unpack the generator or to pass it as a
   single argument. Although this proposal retains existing conventions by
-  treating that form as equivalent to ``f((*x for x in y))``, that may not be
-  immediately obvious.
+  treating that form as equivalent to ``f((*x for x in y))``, that equivalence
+  may not be immediately obvious.
 
 * **Potential for overuse or abuse:**
   Complex uses of unpacking in comprehensions could obscure logic that would be
@@ -723,11 +723,11 @@ were raised as well. This section aims to summarize those concerns.
 
 * **Unclear limitation of scope:**
   This proposal restricts unpacking to the top level of the comprehension
-  expression.  These restrictions may seem arbitrary or surprising to users who
-  expect unpacking to work more generally within expressions.
+  expression, but some users may expect that the unpacking operator is being
+  further generalized as discussed in :ref:`moregeneral`.
 
 * **Effect on External Tools:**
-  As with any new syntactical structure, making this change would create work
+  As with any change to Python's syntax, making this change would create work
   for maintainers of code formatters, linters, type checkers, etc., to make
   sure that the new syntax is supported.