not really C++20

Eh. I've worked on implementing C++ modules for CMake. The issue, as I see it, is that the transition mechanism (header units) are all of the hardest cases of named modules at once. So projects can't make the jump without leaving their consumers behind, maintaining two variants of the build, or some cursed hybrid attempting to support both at once.

There's also the fact that modules are a "new" kind of dependency (well, Fortran had it, but hacks could work around that) that isn't natively supported by the likes of Makefile. It took C++ modules landing to convince Ninja maintainers to accept our patch from 2015 or so which was used by CMake for Fortran support (dyndeps).

I know that…some other developers have griped about CMake's approach, but there are definitely cuts one can make to the supported use cases to make the implementation simpler, but you're definitely leaving use cases on the floor when doing such decisions.

Luckily, the implementations were amenable to P1689 (my ISO paper for dependency communications) which provides the building block that build systems require to properly build modules in the most complicated scenarios.

Documentation for CMake's implementation is here (which includes said use cases and how CMake handles them): https://cmake.org/cmake/help/latest/manual/cmake-cxxmodul...