That's an interesting solution. I would, however, prefer an explicit
binding construct as this can also be used in a local context and
seems to be more in line with how Scheme has been defined so far.
Through the module system, one can still rename, prefix, whatever the
created and exported identifiers.

Your code snippet in a library header would have the following form:

(cond-expand
  ((library (scheme define-auxiliary-syntax))
   (import (scheme define-auxiliary-syntax))
   (begin (define-auxiliary-syntax <> <>)))
  (else
    (begin (define-syntax <> (syntax-rules ...)))))

Am Di., 11. Aug. 2020 um 18:45 Uhr schrieb Jim Rees <xxxxxx@gmail.com>:
>
> I "solved" this on my own implementation with the "auto" library specification and auto-keywords feature.
>
> keywords are generated on demand, guaranteed to always be free-identifier=? to multiple instances of the same name -- and since they're an import spec, you get to do all the tricks with renaming, prefixing, etc. as you please.   By default, they are bound to a macro that does the same thing that (syntax-error ...) does.
>
> This is a decl in my (srfi 26):
>
>   (cond-expand
>    (auto-keywords
>     (import (auto <> <...>)))
>    (else
>     (begin
>       (define-syntax <> (syntax-rules () ((_ . _) (syntax-error "auxiliary syntax" <>))))
>       (define-syntax <...> (syntax-rules () ((_ . _) (syntax-error "auxiliary syntax" <...>)))))))
>
>
> On Tue, Aug 11, 2020 at 3:17 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>>
>> Am Di., 11. Aug. 2020 um 03:29 Uhr schrieb Alex Shinn <xxxxxx@gmail.com>:
>>
>> > Another argument in favor of _ is it's already defined in the core language,
>> > so it won't conflict with future libraries.  If another library provides <> and
>> > you want to use it with SRFI 197, you have to rename one of them.
>>
>> The idea is that at least all SRFI libraries provided by a single
>> implementation use the same binding for each auxiliary syntax like
>> "<>".
>>
>> Using "_" makes it simpler, of course, because there's already a
>> well-known binding of "_" in the base library.
>>
>> In any case, this is a general issue we may want to solve in the
>> course of R7RS-large. For example, SRFI 204 has to export zillions of
>> auxiliary syntax.
>>
>> A possible solution would be a new syntax binding form
>>
>> (define-auxiliary-syntax <id> <name>),
>>
>> where <name> is an identifier. This form would bind <id> to a keyword
>> (or, better, to a syntax parameter if SRFI 139 is supported) that can
>> act as auxiliary syntax and whose identity is given by the symbol
>> <name>. (In other words, these keywords are interned as much as this
>> is already being done for symbols.)
>>
>> So two different libraries could define compatible auxiliary syntaxes
>> through (define-auxiliary-syntax ..1 ..1).
>>
>> Marc