diff --git a/pep-0671.rst b/pep-0671.rst
index b85e56168..ed6d0139c 100644
--- a/pep-0671.rst
+++ b/pep-0671.rst
@@ -60,6 +60,7 @@ Function default arguments can be defined using the new ``=>`` notation::
     def bisect_right(a, x, lo=0, hi=>len(a), *, key=None):
     def connect(timeout=>default_timeout):
     def add_item(item, target=>[]):
+    def format_time(fmt, time_t=>time.time()):
 
 The expression is saved in its source code form for the purpose of inspection,
 and bytecode to evaluate it is prepended to the function's body.
@@ -71,11 +72,13 @@ allows the expression to refer to other arguments.
 Multiple late-bound arguments are evaluated from left to right, and can refer
 to previously-defined values. Order is defined by the function, regardless of
 the order in which keyword arguments may be passed. Using names of other
-arguments is a SyntaxError at function definition time::
+arguments is an error. It is implementation-defined whether this is a syntax
+error or a run-time error, and implementations are free to be more permissive,
+but this should not be relied upon.
 
-    def spaminate(sausage=>eggs + 1, eggs=>sausage - 1): # SyntaxError
-    def selfref(spam=>spam): # SyntaxError
-    def frob(n=>len(items), items=[]): # SyntaxError
+    def spaminate(sausage=>eggs + 1, eggs=>sausage - 1): # Error
+    def selfref(spam=>spam): # Error
+    def frob(n=>len(items), items=[]): # Error
 
 
 Choice of spelling
@@ -86,11 +89,13 @@ Our chief syntax proposal is ``name=>expression`` -- our two syntax proposals
 
     def bisect(a, hi=>len(a)):
     def bisect(a, hi=:len(a)):
+    def bisect(a, hi:=len(a)):
     def bisect(a, hi?=len(a)):
     def bisect(a, hi!=len(a)):
     def bisect(a, hi=\len(a)):
     def bisect(a, hi=`len(a)`):
     def bisect(a, hi=@len(a)):
+    def bisect(a, @hi=len(a)):
 
 Since default arguments behave largely the same whether they're early or late
 bound, the preferred syntax is very similar to the existing early-bind syntax.
@@ -127,17 +132,10 @@ used as dictionary lookup keys, where PEP 671 does not apply.
 Open Issues
 ===========
 
-- yield/await? Will they cause problems? Might end up being a non-issue.
-
-- annotations? They go before the default, so is there any way an anno could
-  want to end with ``=>``?
-
-- Rather than banning future refs, these could be permitted, at the price of
-  harder-to-explain semantics. Arguments would be resolved first with those
-  passed and those with early-bound defaults, and then late-bound ones would
-  be evaluated, left-to-right; the consequences for getting it wrong would
-  then be UnboundLocalError at call time, rather than SyntaxError from the
-  function definition.
+- Annotations go before the default, so in all syntax options, it must be
+  unambiguous (both to the human and the parser) whether this is an annotation,
+  a default, or both. The worst offender is the ``:=`` notation, as ``:int=``
+  would be a valid annotation and early-bound default.
 
 
 Implementation details
@@ -163,6 +161,10 @@ function will begin with the parameter unbound. The function begins by testing
 for each parameter with a late-bound default, and if unbound, evaluates the
 original expression.
 
+Out-of-order variable references are permitted as long as the referent has a
+value from an argument or early-bound default.
+
+
 Costs
 -----