> As I tried to argue in SRFI 72, unless fresh syntax is the default,
> it is easy to reproduce in syntax-case all the unintentional capture
> problems that hygienic macros were invented to solve in  the first
> place.

No, it's not.  In fact, it is impossible to reproduce any of the
unintentional capture problems that hygienic macros were invented to
solve.

The original hygiene condition for macro expansion (Kolbecker, at al,
1986) is stated as follows:

  Generated identifiers that become binding instances in the completely
  expanded program must only bind variables that are generated at the same
  transcription step.

The condition has been refined over time, but the basic notion has always
been that the bindings and references introduced by a transformer call
cannot conflict unintentionally with the bindings and references present
in the source or introduced by a different transformer call.

The traditional model adopted by SRFI 93, which is implemented by applying
a single fresh mark to all identifiers introduced by a given transformer
call, is sufficient to ensure that the hygiene condition for macros is
met.  The fresh mark prevents introduced identifiers from conflicting with
identifiers present in the source or introduced by other transformer
calls.

The unintended captures that can be reproduced, such as the ones that you
described in your note and in SRFI 72, are of a different, less common,
and less troublesome sort.  They are "intra-transformer" captures, which
can occur only when the same transformer call introduces two bindings for
the same identifier.

While I agree it might be nice to protect against this limited sort of
unintended capture, and the SRFI 72 model, which applies a fresh mark to
the introduced identifiers of each syntax form, can prevent some of this
sort of capture, I prefer not to switch to the SRFI 72 model for the
following reasons.

 * The SRFI 72 model would generally complicate without benefit macros
   that are self-contained, i.e., have only local helpers.  I believe that
   most macros fall into this category.  For such macros, it's easy to
   avoid using the same name for conflicting bindings, and would be
   awkward to explicitly pull out and commonize the identifiers that
   should be the same.

 * The SRFI 72 model would be an incompatible change affecting a large
   corpus of syntax-case macros written over the dozen or so years since
   syntax-case was introduced.  Furthermore, identifying the places
   affected by the change would be nontrivial.

The SRFI 72 model does have its merits, and, as I mentioned privately
back when you were still designing the SRFI 72 system, we've seriously
considered the model ourselves.  I just don't believe the benefits
outweigh the costs.

Kent