The draft says:

  No implementation is provided because this is SRFI is merely a
  request to add two basic features to the SYNTAX-RULES pattern
  language, and so the implementation of it would be a modification of
  an implementation of SYNTAX-RULES.

I think that's bogus.  It's true that RFI stands for "Request For
Implementation", but that should be taken as "Request for others to
implement in the same way what I have found to work well" rather than
"Request for someone to implement my idea that's never been tried,
even by me".

Even though it's impossible to provide a simple implementation that
everyone can just drop into their system, I think it's still valuable
to have something that at least proves the idea is implementable, and
that people can look to for guidance if the English specification is
later found to be self-contradictory.

One advantage of the original (... ...) idea over
choose-your-own-ellipsis is that it is already widely implemented, and
you could use the free somewhat-portable syntax-case expander from
chez scheme as the reference implementation.

If you opt for the more pioneering CYOE concept, then you could
perhaps provide a modified version of the chez scheme expander.  An
advantage of the chez-scheme expander is that it is used by several
systems (like SISC and Chicken, IIRC), and patches to it could
actually be used by those systems' implementors.

Another option, more in the "so at least people have something to look
at" category, would be to use the macro expander I have been working
on occasionally, available at petrofsky.org/src/alexpander.scm, which
I just updated to include support for CYOE and tail patterns.  (I also
added a few pages of commentary, but it doesn't rise to the level of
comprehensibility yet.)

I just noticed that the draft only allows one extra pattern after an
ellipsis.  Don't you want to allow any number, as in Chez scheme?
That's the way I implemented it.

-al