Thanks to Marc, Al, and Takashi, we have figured out what is wrong
with the current sample implementations of SRFI 147 and SRFI 148.

The short answer is that they work in systems that use something
akin to free-identifier=? when determining whether an identifier
is a pattern variable or a literal, but don't work in systems
that use something akin to bound-variable=? for that decision.

To put it less technically, the sample implementations work only
in macro systems that are (intuitively) less hygienic than those
used by R6RS systems such as Chez, Petite Chez, Racket, Vicare,
Larceny, and the -r6 mode of Sagittarius.

Alfalfa Petrofsky wrote:

> I agree with Will that bound-identifier=? is the better comparison,
> and that's the way I implemented it in Alexpander and Eiod.  The
> literals list is logically a binding construct: it declares that some
> identifiers will have a different meaning within the scope of the
> declaration.  It should therefore follow the hygienic rules for
> bindings.
>
> I also agree that none of the RnRS specify the answer.  It's made
> clear that free-identifier=? is to be used for comparing the
> identifier in the macro use with the identifier in the pattern, but
> that's a different comparison from the one we're talking about
> (between the identifier in the pattern and the one in the literals
> list).

Because the relevant standards do not specify this detail of
macro processing, programs that depend upon the less hygienic
behavior are not portable.  That's why the sample implementations
of SRFI 147 and 148 work in some systems but not in others.

I have repaired the sample implementation of SRFI 147 by changing
it to use the string ":continuation" instead of the identifier
:continuation.  That kind of change is not quite trivial, because
you have to

    change :continuation to ":continuation" in patterns,
    delete :continuation from literals lists,
    which implies deleting :continuation from templates that are
        inserting it into what will eventually become a literals
        list,
    while changing :continuation to ":continuation" in templates
        that are inserting it so it can be recognized as a flag
        by subsequent macro processing.

Distinguishing between those last two situations requires knowledge
of the intended use of the identifier being inserted, so I leave it
for Marc to repair the sample implementation of SRFI 148, following
the example of SRFI 147 whose repair diff is here:

https://github.com/larcenists/larceny/commit/d033e7e6d9240d606ee7f5246583fc174fba2b07

With that repair to SRFI 147, the sample implementation of SRFI 148
still fails to be portable, but it is now failing only because it
uses the same non-portable technique for recognizing flags such as
quote, quasiquote, :prepare, :call, em-cut, em-cute, and possibly
a few other things such as ... and =>.  In particular, one of the
renamed quote identifiers ends up as a pattern variable (in the
more hygienic macro systems), leading to an error when the macro
system detects multiple occurrences of that pattern variable
within a pattern.

Will