The biggest lesson for me is that you need to provide an incremental path to using the new features. The reason C++ succeeded as much as it did is because you c

The biggest lesson for me is that you need to provide an incremental path to using the new features. The reason C++ succeeded as much as it did is because you can incrementally C++-ify your existing C code. You can provide C interfaces to your new C++ stuff and you can use C interfaces from C++. Any new feature that you add to C++ has to offer such a path. That is why move semantics were very successful - you could add them incrementally and you could put a preprocessor guard around their definition so your library could be used by code written for both older and newer C++. In contrast, it is hard to incrementally module-ify. You can't transform half of your library to a module and I haven't seen a good story on how to offer a library as both a module and as traditional headers. So it's hard to adopt modules in an existing codebase, thus it's hard to get good feedback on them, thus modules took a long time to really iron out. Offering a path to incremental improvement is very important for large projects where features and bugfixes happen constantly. We can't stop our regular work to untangle the whole carefully built system of dependencies. The new features have to be offered in a form where we can use them in new code, while remaining compatible with old code and gradually add them to it as time permits.