diff --git a/pep-0340.txt b/pep-0340.txt
index 36da827da..5853e7039 100644
--- a/pep-0340.txt
+++ b/pep-0340.txt
@@ -373,12 +373,28 @@ Specification: Generator Exit Handling
     cases work differently; in Python, you cannot save the block for
     later use, and you cannot test whether there is a block or not.
 
-Alternatives Considered
+Alternatives Considered and Rejected
 
-    - Many alternatives have been proposed for 'block', including '@'
-      and no keyword at all.  I haven't seen a proposal for another
-      keyword that I like better than 'block' yet, and not using a
-      keyword at all makes many folks (including me) uncomfortable.
+    - Many alternatives have been proposed for 'block'.  I haven't
+      seen a proposal for another keyword that I like better than
+      'block' yet.  Alas, 'block' is also not a good choice; it is a
+      rather popular name for variables, arguments and methods.
+      Perhaps 'with' is the best choice after all?
+
+    - Instead of trying to pick the ideal keyword, the block-statement
+      could simply have the form:
+
+        EXPR1 as VAR1:
+            BLOCK1
+
+      This is at first attractive because, together with a good choice
+      of function names (like those in the Examples section below)
+      used in EXPR1, it reads well, and feels like a "user-defined
+      statement".  And yet, it makes me (and many others)
+      uncomfortable; without a keyword the syntax is very "bland",
+      difficult to look up in a manual (remember that 'as' is
+      optional), and it makes the meaning of break and continue in the
+      block-statement even more confusing.
 
     - Phillip Eby has proposed to have the block-statement use
       an entirely different API than the for-loop, to differentiate
@@ -388,6 +404,20 @@ Alternatives Considered
       that the block-statement is conceptually a loop -- it supports
       break and continue, after all.
 
+    - This keeps getting proposed: "block VAR1 = EXPR1" instead of
+      "block EXPR1 as VAR1".  That would be very misleading, since
+      VAR1 does *not* get assigned the value of EXPR1; EXPR1 results
+      in a generator which is assigned to an internal variable, and
+      VAR1 is the value returned by successive calls to the __next__()
+      method of that iterator.
+
+    - Why not change the translation to apply iter(EXPR1)?  All the
+      examples would continue to work.  But this makes the
+      block-statement *more* like a for-loop, while the emphasis ought
+      to be on the *difference* between the two.  Not calling iter()
+      catches a bunch of misunderstandings, like using a sequence as
+      EXPR1.
+
 Comparison to Thunks
 
     Alternative semantics proposed for the block-statement turn the