The spec fails to say that s-expressions are n-expressions.

For "We encourage implementations to *always* implement curly-infix
expressions" read "Implementations SHOULD implement c-expressions".

For "Applications should" read "Applications SHOULD".

For "We recommend that portable applications do *not*" read "Applications
SHOULD NOT".

For "We encourage implementations' *default* invocation" read "An
implementation's default implementation SHOULD", and remove ", but this
is not required".

As mentioned earlier, remove the sentence about "curly-foo"

What is said about defining "nfx" should also be said about
"$bracket-access$".

For "(curly-infix-read . port)" read something like "curly-infix-read
with an optional port argument.

Add the following boilerplate to the top of the specification:

      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL"
      in this document are to be interpreted as described in RFC 2119.

I recommend the use of small capital letters rather than
italics for these key words: this can be achieved in HTML with
<small>MUST</small>, <small>SHOULD</small>, etc.  or in HTML/CSS with
<span style="font-variant: small-caps;">must</span>, etc.

--
Unless it was by accident that I had            John Cowan
offended someone, I never apologized.           xxxxxx@ccil.org
        --Quentin Crisp                         http://www.ccil.org/~cowan