Honestly, I have no idea, because I have not even so much looked at what the actual implementation of modules is like in C++20 yet. Haiku uses almost none of the STL as it is, we write almost all our own containers and use C++ merely as "C with Classes" more than anything else.

I think if we had sufficient time and energy, we might have started our own programming language that takes a lot from C++ but would diverge sharply after the "C with Classes" part (we have joked about it before, at least.) For one, some of the paradigms we use a lot in Haiku might serve well as baked-in language features, or could be taken further with compiler support. Memory safety is also another big one; I know Rust is now the "C++ successor with memory safety," but at least to me I think it does not quite fit the bill; though we have an especially esoteric view of what "C++" is (notably I haven't put in the time to really learn Rust, honestly, though some of the other Haiku contributors are fans, and the Rust port to Haiku is sufficiently solid at this point)

The biggest thing I think we would ultimately change in any wildly hypothetical programming language we might come up with, though, would probably be ABI stability. C++ is just a huge pain to keep ABI-stable (C is as well, to a lesser extent), and there are all kinds of tricks that are clearly possible now in compilers, in ELF, etc. that there is clearly room for a slightly different language design coupled with a radically different language ABI to make ABI stability much less of a chore to maintain. (We are very big on dynamic linking and stable ABIs, something Rust seems to have basically given up on if it ever really tried, and the same in Go and other newer languages.)

I would imagine that modules instead of headers might come about as some kind of development along with ABI stability if nothing else.