[Boris]

| > 1. A (set of) module description file(s) that specifies:
| > 1. A map from a module name to the file name for the module
| > interface unit source code.  A default naming convention could
| > also be adopted, though we already have two competing
| > conventions (.cppm vs .ixx).
| > 2. A set of requirements for translating the module interface unit
| > source code (for one or more variations or build modes).  This
| > includes preprocessor information (include paths, macro
| > definitions, macro undefinitions), and, potentially, language
| > dialect requirements (specified in a generic form and, perhaps,
| > with the ability to customize for specific tools).
| > 2. A method of specifying a path to search for module description
| > files, similar to existing include paths.
|
| I would argue against any kind of "search paths" approach (whether for
| modules or description files themselves). We've used them for includes
| and I think it has proven to be brittle (I am talking about the "header
| doesn't exist where you expect it to exist but the compiler found you
| another one" kind of situtions) and not toolable (where shoudl I generate
| this non-existent header?)

Strongly seconded.

One of the early decisions - based on decades of experience - for the Microsoft implementation
is to
   1. dissociate module-names from file-names
   2. not rely on search paths, because of the associated havoc they cause

Hence the "/module:reference" option.
However, some people liked the "convenience" of search path for small examples, so we added the "/module:search" option.

The Microsoft recommendation to its customers is to strongly prefer file mapping references over search paths.

-- Gaby