Mark H Weaver:
> First, a small typo:
>
>  6. These MUST recurse within lists and vectors, so any list or vector
>     in a position that accepts a neoteric expression MUST accept a
>     sequence of zero or more neoteric expressions, not just
>     s-expressions. (Note that this occurs if they are directly or
>     directly within a curly-infix list or a neoteric-expression.) [...]
>     ^^^^^^^^
>
> Presumably that should be "directly or indirectly", not "directly or
> directly".

Absolutely correct.  Typo fixed.

>     An implementation of this SRFI MUST accept the marker #!curly-infix
>     followed by a whitespace character in its standard datum readers
>     (e.g., read and, if applicable, the default implementation
>     REPL). This marker (including the trailing whitespace character)
>     MUST be consumed and considered whitespace. After reading this
>     marker, the reader MUST accept curly-infix expressions in subsequent
>     datums until it reaches an end-of-file or some other conflicting
>     marker (no conflicting marker is specified here).
>
> I'd prefer to change the language "[...] in subsequent datums until it
> reaches an end-of-file [...]" to something closer to "[...] in
> subsequent datums read from the same port [...]".  This is based on the
> text in section 2.1 of R7RS (draft 6) that describes #!fold-case and
> #!no-fold-case:
>
>     #!fold-case
>     #!no-fold-case
>
>     These directives may appear anywhere comments are per- mitted (see
>     section 2.2) and are treated as comments, except that they affect
>     the reading of subsequent data.  The #!fold-case directive causes
>     the read procedure to case-fold (as if by string-foldcase; see
>     section 6.7) each identifier and character name subsequently read
>     from the same port. (It has no effect on character literals.) The
>     #!no-fold-case directive causes the read procedure to return to the
>     default, non-folding behavior.
>
> There is a functional difference between the two formulations when
> reading from a terminal.  On POSIX systems, a terminal device will
> return EOF when CTRL-D is pressed, but then subsequent reads may
> continue to read more data.
>
> This raises the question of whether the #!curly-infix read option should
> be reset to the Scheme implementation default when CTRL-D is pressed at
> a terminal.  I interpret the current language to mean that the flag
> should be reset, but I would prefer that the flag retains its setting as
> long as the port exists.
>
> Following the R7RS language also simplifies the handling of reader
> directives by giving them uniform behavior, and also makes it crystal
> clear that the flag should be set on a per-port basis (as opposed to a
> global flag for the process or thread).
>
> What do you think?

Sounds like a great rationale to me.  In general, we want to be consistent with how other things are done unless there's a strong reason not to be.

New text:

"After reading this marker, the reader <em>MUST</em> accept
curly-infix expressions in subsequent datums
read from the same port until some other conflicting marker is given
(no conflicting marker is specified here)."

--- David A. Wheeler