I have fixed a 10-year-old bug in Larceny's macro expander.
(That fix is not in the nightly build available this morning,
but will be in the nightly build to go out tomorrow morning.)

Following that repair, the sample implementation of SRFI 148
is mostly working, but I am still getting an error for the
"em-free-identifier=?: false" test because

(letrec-syntax
  ((m
    (syntax-rules ()
     ((m a)
      (em (em-quote
           (em-if (em-free-identifier=? 'a 'm) 'true 'false)))))))
  (m c))

is expanding into code that contains something Larceny's macro
expander prints as

(scheme-syntax-rules
  :::2
  (c :continuation)
  ((_ (:continuation c :::2) c %%kt %%kf)
   (c :::2 %%kt))
  ((_ (:continuation c :::2) x %%kt %%kf)
   (c :::2 %%kf))
  ((test c %%kt %%kf) %%kt)
  ((test x %%kt %%kf) %%kf))

That code has been de-mangled for readability, so I can't tell
for sure whether the "c" in the literals is the same identifier
as the "c" that occurs in patterns and templates, but I think
something is wrong here either way, unless the first "c" in the
pattern for the first rule is a pattern variable but the second
"c" in that pattern is a literal.

There's a question as to whether a syntax-rules literal can be
followed by an ellipsis.  Actually, there are two questions.

On my reading of the R6RS and R7RS, it is probably legal for a
literal to be followed by an ellipsis in patterns.  In templates,
however, R6RS 11.19 implies a literal cannot be followed by an
ellipsis:

    A subtemplate followed by an ellipsis expands into zero
    or more occurrences of the subtemplate....The subtemplate
    must contain at least one pattern variable from a subpattern
    followed by an ellipsis, and for at least one such pattern
    variable, the subtemplate must be followed by exactly as
    many ellipses as the subpattern in which the pattern
    variable appears. (Otherwise, the expander would not be
    able to determine how many times the subform should be
    repeated in the output.) It is a syntax violation if the
    constraints of this paragraph are not met.

The R7RS prose is less clear, but I don't think the R7RS differs
from the R6RS on this point.

Whether the use of scheme-syntax-rules shown above is correctly
transcribed from the original expression is a different question.
There could, of course, be other bugs in Larceny's macro expander.
I'm just reporting what I know at the moment, in hope Marc will
figure out what's going on.

Will