John, I don't think that what you have commented about is related to
what we have been discussing (unless I misunderstood you). What I have
been discussing with Jim lately is the following: If a library exports
an identifier `foo', one can access all (not renamed) identifiers that
are defined at the top-level of the library, namely through
(datum->syntax #'foo top-level-identifier-name) or a similar
construction for the given macro system that allows unhygienic
bindings. Therefore, not only the set exported identifiers but also
the top-level environment of a library is an observable quantity. And
the latter can behave quite differently:

(1) One library may completely alias another one. In this case, the
top-level environments and the set of exports are the same.
(2) One library may extend (possibly trivial) another library. In this
case, the top-level environments are disjoint.
(3) One library adds the exports of another library to its own exports
without importing the other library itself. In this case, the
top-level environments are again disjoint.

Am Mi., 23. Sept. 2020 um 23:45 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
> Just a reminder that the define-library language is not Scheme, and in particular, macro expansion can neither create a define-library nor can it create a clause or list of clauses.  (Of course macro expansion is done in the *body* of a begin-clause, because that is Scheme.)
>
> On Wed, Sep 23, 2020 at 8:58 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>>
>> Am Mi., 23. Sept. 2020 um 14:52 Uhr schrieb Jim Rees <xxxxxx@gmail.com>:
>> >
>> > On Wed, Sep 23, 2020 at 2:02 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>> >>
>> >>
>> >> What do you exactly mean by "does not contaminate the local
>> >> environment"? That the hypothetical library body of, in this example,
>> >> (scheme list) does not see the bindings of (srfi 1)?
>> >
>> >
>> > Exactly.   I wanted to isolate the effects of export-from and import from each other.
>>
>> I would suggest merging this with `define-library-alias', which would
>> then become `define-library-composition'. What do you think?
>>
>> In any case, this discussion shows that one shouldn't add extensions
>> to the module language lightly as the semantics can be surprising when
>> low-level macros and unhygiene is involved.