Perhaps the best option is to default the visibility of the implicit functions to the widest visibility of any function or object in module purview exposed by the TU. The assumption being that if anything is visibile outside the library, then it is expected to be imported from TUs outside the library and that should Just Work. Conversely, if everything is defined as internal visibility, then it is unlikely that this module was intended to be imported from outside of the library, and so it may be desireable to allow different libs to have their own module with the same name.

Unfortunately that doesn't give any good indication of what to do for importable units that have an empty module purview (or where everything inside it has TU-local internal linkage). While legal, maybe that isn't a case worth optimizing the Just Works experience for?

> Perhaps the best option is to default the visibility of the implicit functions to the widest visibility of any function or object in module purview exposed by the TU.

What to do about `extern "C"` APIs made available by a module? Is that even allowed? Imagine a library providing some C API by implementing in C++ modules; should the module initializer be public API too?

the import places attributes at the end.

so 
import module Foo [[....]];

it would seem to be symmetrical to have:

export import Foo [[...]];
export module Foo [[...]];

but, ts present, (if I read it correctly) it seems that the WD says

export [[...]] module Foo;
export [[...]] int bar ();

which would then be weird with export [[...]] import Foo [[...]];