With Marc's permission, I'm sharing his proposed past-finalization note for SRFI 149.

Please let us know what you think.  I'll wait one week for feedback.

Thank you.
---------- Forwarded message ----------
From: "Marc Nieper-Wißkirchen" <xxxxxx@nieper-wisskirchen.de>
Date: Jul 28, 2017 7:47 AM
Subject: Post-finalization note for SRFI 149
To: "SRFI Editors" <xxxxxx@srfi.schemers.org>, "Arthur A. Gleckler" <xxxxxx@speechcode.com>
Cc:

Hi Arthur,

here is the promised post-finalization note for SRFI 149.

<p>
After finalization of this SRFI, a discussion (starting <a href="https://srfi-email.schemers.org/srfi-149/msg/6057423">here</a> on the mailing list) revealed that the behaviour of this SRFI when a pattern variable in a subtemplate is followed by more instances of <code>&lt;ellipsis&gt;</code> than the subpattern in which it occurs differs from how implementations of the R6RS handle this case.  While this SRFI specifies that the input subform is repeated for the innermost excess instances of <code>&lt;ellipsis&gt;</code>, the implementations of the R6RS repeat for the outermost excess instances.
</p>

<p>
There is no obvious reason to prefer one convention over the other as their are interesting macros that work with the former convention and not with the latter convention, and vice-versa.
</p>

<p>
However, this means that an implementation supporting the R6RS-semantics of <code>syntax-rules</code> can never properly support this SRFI because this SRFI requires that <code>(srfi 149)</code> and <code>(scheme base)</code> export the same <code>syntax-rules</code>.
</p>

<p>
Therefore, the author of this SRFI now recommends that implementers ignore this extra requirement so that <code>(srfi 149)</code> may export a version of <code>syntax-rules</code> compatible with this SRFI and <code>(scheme base)</code> may exports another.  Instead, it is recommended that implementations provide a feature identifier <code>srfi-149</code> in case the implementation of <code>syntax-rules</code> in <code>(scheme base)</code> has the semantics as specified in this SRFI.
</p>

Marc