That definition only applies to the cond-expand *macro*, not the cond-expand *library declaration*.  Macros cannot expand to libraries, so symbolic matching is the correct thing in any define-library form.  Note also that the definition of cond-expand given does not correctly interact with (features).

I personally dislike and avoid the cond-expand and include macros and always use the library declarations instead.



On Sun, Sep 27, 2020 at 3:17 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
It should also be noted that some bugs may be considered features by
some implementations.

For example, the hygienic definition of "cond-expand" in section 7.3
in the R7RS (and the categorization of "cond-expand" as a hygienic
derived form in section 4.2 is pointless because it amounts to
hygienic matching of identifiers against library name part, meaning
that the matching of the cond clause, say, (library (scheme read))
will depend on the binding of the identifiers `library', `scheme', and
`read'. Therefore, I took liberties in Unsyntax to do the matching in
cond-clauses by symbol equality. Strictly speaking, this is an
incompatibility with R7RS as written, but probably conforming to the
intended meaning.

Am So., 27. Sept. 2020 um 20:47 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
> A list of nonconformities for each R7RS implementation would be better and simpler, I think, than trying to reduce it all to a single number.  In principle I think this should be included with the implementation itself, like the BUGS section on man pages.
>
> On Sun, Sep 27, 2020 at 1:53 PM Lassi Kortela <xxxxxx@lassi.io> wrote:
>>
>> > Guile's R7RS library level looks quite broken. A number of bug reports
>> > have been filed. We have to wait until they are resolved.
>>
>> Good to get a status update on that. No R7RS implementation is yet
>> complete (not even R7RS-small). Slowly but surely getting there.
>>
>> It would be fun to have some kind of scoreboard on conformance, if
>> anyone has time/ideas for how to make one.