• It seem like a net-negative change to make #include <foo> and import <foo> mean different things in cases where both are well-formed.

 

I think that is an inevitable practical necessity.

Actually, I think it is a real net-positive: we can practically deploy it, enable incremental adoption, and update the toolchains to identify incoherent context settings.

I strongly disagree with this being a net-positive.  If programmers can't rely on translation of #include <foo> to import <foo>, then code written to compile for C++17 and C++20 can't take advantage of modules when compiled as C++20 unless the code is #ifdef'd to use #include in C++17 mode and import in C++20 mode.  This hurts the incremental adoption story.

Clang modules took the approach that importable headers must be defined in a module map.  My expectation has been that the SG15 TR would (eventually) specify a portable map format to enable specifying which headers are importable.  That remains my preference.  As a programmer, I want to be able to control which of my headers are importable; it matters from a build system perspective because I may want to pre-build module artifacts for a select set of headers (ideally a set that the build system learns from the module map file(s); assuming compilers provide the ability to explicitly generate module artifacts for header units).

Tom.