Andy Wingo scripsit:
> This question is about identifiers that are not present in the macro
> input, and which are free relative to the definition of the macro
> (not a pattern variable, not a lexical variable, not a module-level
> variable).
Ah, thanks. Yes, letting such names leak would suck.
From an R6RS-ish (syntax-case library) point of view, such an "introduced" identifier would be have a "mark" on it after returning from the expander. It would not, therefore, be bound-identifier=? to a similar-named identifier already defined in your top-level without the same mark. The only thing that could even refer to this "marked" definition would be other code generated by *same* macro call.
Of course, the effect you fear *can* be implemented on purpose from the macro with the use of datum->syntax. And sometimes, you might even want this (think R6RS-style define-record-type with implicit constructor, predicate, accessor names).