Per Bothner scripsit:

> First, a question: Do you have any objection to plain & for SRFI-109
> strings:
>   &{text}

No, that's fine.

> A possible solution/compromise is to *require* that "&name[initial-exp]"
> be followed by a braced-delimited literal part, if necessary empty:
>   &name[initial-exp]{}
> This avoids the incompatibility.

I can live with that.  I have yet to be convinced once and for all that
initial-expressions are actually as useful as all that.  I'd rather
leave them as an optional extension.

> But in this case I lean towards preferring the nicer syntax,
> given that it may be hard to find actual programs that would break.

Probably, but the difference is one of whitespace only, and it makes

    (foo &condition [bar 1 2])

and

    (foo &condition[bar 1 2])

differ very radically.  If initial & was rare, I'd probably feel better
about this, but it's common in SRFI 35 or R6RS code that deals with
conditions.

> For XML literals I think we're stuck with "#<TAG..." rather than
> "<TAG..." since the latter conflict with existing code an
> standards is much more difficult.  For example some Schemes
> have "<type-name>" which is obviously a pretty nasty conflict.

I agree.

--
While staying with the Asonu, I met a man from      John Cowan
the Candensian plane, which is very much like       xxxxxx@ccil.org
ours, only more of it consists of Toronto.          http://www.ccil.org/~cowan
        --Ursula K. Le Guin, Changing Planes