fix a few typos, add a brief note to backwards compatibility section

Author: adqm

peps/pep-0798.rst

@@ -398,9 +398,12 @@ expect to be rare.
 
 One related concern is that a hypothetical future decision to change the
 semantics of async generator expressions to make use of ``yield from`` during
-unpacking (delegating to generators that are being unpacked) would be not be
+unpacking (delegating to generators that are being unpacked) would not be
 backwards-compatible because it would affect the behavior of the resulting
-generators when used with ``.asend()``, ``.athrow()``, and ``.aclose()``.  See
+generators when used with ``.asend()``, ``.athrow()``, and ``.aclose()``.  That
+said, despite being backwards-incompatible, such a change would be unlikely to
+have a large impact because it would only affect the behavior of structures
+that, under this proposal, are not particularly useful.  See
 :ref:`pep798-alternativegenexpsemantics` for more discussion.
 
 .. _pep798-examples:
@@ -780,7 +783,7 @@ Beyond the proposal outlined above, the following were also considered:
    expressions do gain support for ``yield from`` in the future by making sure
    that any decision made at that point would be fully backwards-compatible.
    But the utility of unpacking in that context seems to outweigh the potential
-   downside of a backwards-incompatible change in the future if aync generator
+   downside of a backwards-incompatible change in the future if async generator
    expressions do receive support for ``yield from``.
 
 4. Disallowing unpacking in all generator expressions.