diff --git a/pep-0649.rst b/pep-0649.rst
index c85484f15..a52951437 100644
--- a/pep-0649.rst
+++ b/pep-0649.rst
@@ -219,6 +219,37 @@ has the correct value--the class ``MyType``--even though
 defined.
 
 
+Mistaken Rejection Of This Approach In November 2017
+====================================================
+
+During the early days of discussion around :pep:`563`,
+in a November 2017 thread in ``comp.lang.python-dev``,
+the idea of using code to delay the evaluation of
+annotations was briefly discussed.  At the time the
+technique was termed an "implicit lambda expression".
+
+Guido van Rossum—Python's BDFL at the time—replied,
+asserting that these "implicit lambda expression" wouldn't
+work, because they'd only be able to resolve symbols at
+module-level scope:
+
+    IMO the inability of referencing class-level definitions
+    from annotations on methods pretty much kills this idea.
+
+https://mail.python.org/pipermail/python-dev/2017-November/150109.html
+
+This led to a short discussion about extending lambda-ized
+annotations for methods to be able to refer to class-level
+definitions, by maintaining a reference to the class-level
+scope.  This idea, too, was quickly rejected.
+
+:pep:`PEP 563 summarizes the above discussion
+<563#keeping-the-ability-to-use-function-local-state-when-defining-annotations>`
+
+The approach taken by this PEP doesn't suffer from these
+restrictions.  Annotations can access module-level definitions,
+class-level definitions, and even local and free variables.
+
 
 **********
 Motivation
@@ -491,37 +522,6 @@ approach to solve the problems facing annotations users,
 resulting in this PEP.
 
 
-Mistaken Rejection Of This Approach In November 2017
-====================================================
-
-During the early days of discussion around :pep:`563`,
-in a November 2017 thread in ``comp.lang.python-dev``,
-the idea of using code to delay the evaluation of
-annotations was briefly discussed.  At the time the
-technique was termed an "implicit lambda expression".
-
-Guido van Rossum—Python's BDFL at the time—replied,
-asserting that these "implicit lambda expression" wouldn't
-work, because they'd only be able to resolve symbols at
-module-level scope:
-
-    IMO the inability of referencing class-level definitions
-    from annotations on methods pretty much kills this idea.
-
-https://mail.python.org/pipermail/python-dev/2017-November/150109.html
-
-This led to a short discussion about extending lambda-ized
-annotations for methods to be able to refer to class-level
-definitions, by maintaining a reference to the class-level
-scope.  This idea, too, was quickly rejected.
-
-:pep:`PEP 563 summarizes the above discussion
-<563#keeping-the-ability-to-use-function-local-state-when-defining-annotations>`
-
-The approach taken by this PEP doesn't suffer from these
-restrictions.  Annotations can access module-level definitions,
-class-level definitions, and even local and free variables.
-
 .. _Implementation:
 
 **************
@@ -580,9 +580,10 @@ Language Reference:
     ``2`` (exported as ``inspect.SOURCE``)
 
         Values are the text string of the annotation as it
-        appears in the source code. May only be approximate;
+        appears in the source code.  May only be approximate;
         whitespace may be normalized, and constant values may
-        be optimized.
+        be optimized.  It's possible the exact values of these
+        strings could change in future version of Python.
 
     ``3`` (exported as ``inspect.FORWARDREF``)
 
@@ -680,7 +681,24 @@ an object of any of these three types:
     creates, caches, and returns a new empty dict.  (This is for
     backwards compatibility with :pep:`3107` semantics.)
 
+Changes to allowable annotations syntax
+=======================================
 
+``__annotate__`` now delays the evaluation of annotations until
+``__annotations__`` is referenced in the future.  It also means
+annotations are evaluated in a new function, rather than in the
+original context where the object they were defined on was bound.
+There are four operators with significant runtime side-effects
+that were permitted in stock semantics, but are disallowed when
+``from __future__ import annotations`` is active, and will have
+to be disallowed when this PEP is active:
+
+```
+:=
+yield
+yield from
+await
+```
 
 Changes to ``inspect.get_annotations`` and ``typing.get_type_hints``
 ====================================================================