The lynchpin of C++ modules is the built module interface (BMI). Each BMI is meant to be a lightweight data structure representing the syntax of a module unit (comprised of one primary module interface and potentially one or more partitions), with approximately O(1) complexity of symbol lookup. This massively accelerates repeated lookups into the same translation unit, and avoids paying the cost of a full preprocessor run and front-end lex + parse, as might otherwise happen with header files. In this way both the first clean build, and incremental builds are considerably accelerated and made much more efficient—build the BMI once, reuse it across future compiles, and we don't need large core counts and massively parallel jobs because the BMI is now available afterwards.
However, the way compiler toolchains have actually implemented them seems diametrically opposed to this goal of fast lookup. Today, BMIs are highly sensitive to any change in the command-line invocation of the compiler/dependency scanning tool, including the C++ version, warning and feature flags, and especially macro definitions, with -DMACRO or /DMACRO. This means that changing just one flag is likely to cause a BMI cache miss and a full BMI reconstruction, which can be fairly slow for larger modules (like module std).
BMIs are considered implementation details, and aren't even stable across compiler versions within the same toolchain. Compare to object files, where something compiled by really old versions can still be used on newer versions without too much fuss. This, from the user's perspective, entirely defeats that design ideal mentioned above: fast repeated lookups. Consider a simple example: a certain module uses a project-specific macro representing the platform, to change several function signatures. This module is now precompiled thrice, once each for -DFOO_WINDOWS, -DFOO_DARWIN, -DFOO_LINUX, instead of just once.
I believe that macros and the preprocessor are highly problematic. However, their very limitations are also an advantage here: their effect on code collapses to completely binary decisions. A macro is either defined or not, and a macro is either in the set of accepted values, or it isn't (e.g. #if __cplusplus >= 202603L). The preprocessor state might change throughout the source code of a translation unit, but the entire set of possible states can be enumerated in finite and reasonably short time at compile time—otherwise the front-end would never complete its work. To me, this seems like the preprocessor and parser could enumerate all possible preprocessor states of the source code, and stamp out both possibilities for each macro switch in the BMI; during lookup, the compiler can select the correct code path depending on what is provided at that particular invocation (not code definitions, but command-line invocations, as this would break the module assurance that macros do not leak into BMIs from consumers, nor do consumers see macros from a BMI).
This would make things like library feature configuration with macros really straightforward—specify the macros one wants for that feature at the command-line, which is enshrined in build system code rather than source code—the BMI can be reused, done.
Now, the compiler and C++ standard are a lot harder as these probably affect the internal state of the compiler rather than merely the value of __cplusplus; however, I genuinely feel like there really ought to be a better way forward, especially if C++ is to continue as a 'source may not be available' language. This discussion is moot if we always want to compile from source, but I want to say that is wasteful, and another driving force of the modules feature was to do away with wasteful and repeated recomputation of the same thing.
As mentioned above, build systems are also forced into this rather inefficient model to accommodate compiler behaviour. CMake in its latest iteration, for instance, has a notion of 'BMI compatibility', and probably does some sort of set manipulation on compile flags to determine if another BMI for the same module interface is needed or not, based on how it is imported. Why? This shouldn't be the case, a BMI really ought to be widely (if not universally) compatible, regardless of what flags go in the command-line.
I'm sure I don't have the entire picture as I am not a compiler front-end developer, and I don't mean to sound impertinent here, the effort put into delivering modules has been huge. However there are some decisions made which, as modules user and advocate, seem a little contradictory to the spirit of modules. I've written this after some thought on the situation and I'm interested in hearing from the community and compiler front-end developers who have worked on modules on my thoughts above.
Cheers.