It's the fault of built systems.
CMake still doesn't support `import std` officially and undocumented things are done in the ecosystem [1]
But once it works and you setup the new stuff, having started a new CPP26 Project with modules now, it's kinda awesome. I'm certainly never going back. The big compilers are also retroactively adding `import std` to CPP20, so support is widening.
I wanted to ship import std in 4.3 but there are some major disagreements over where the std.o symbols are supposed to come from.
Clang says "we don't need them", GCC says "we'll ship them in libstdc++", and MSVC says "you are supposed to provide them".
I didn't know about that when I was working on finishing import std for CMake and accidentally broke a lot of code in the move to a native implementation of the module manifest format, so everything got reverted and put back into experimental.
You are of course right. It's just that Modules inherently put a lot of responsibility on the build system. Among those, but not limited to: a "module registry" wasn't standardized and is in the hands of the build system.
Systems like ninja needs to know modules, which took time and then a stack further up systems like CMake needed to know modules, which took time. That's my answer to the parent "why are there so few modules projects". Because it took time for the ecosystem to catch up.
But once it works and you setup the new stuff, having started a new CPP26 Project with modules now, it's kinda awesome. I'm certainly never going back. The big compilers are also retroactively adding `import std` to CPP20, so support is widening.
[1] https://gitlab.kitware.com/cmake/cmake/-/work_items/27706