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".

    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?

    Regards,
      Mark