Nevertheless, I'd like to know everyone's opinion on the subject. If we find a way to overcome the technical challenges that I manifest in the article, do you think a set of non-intrusive "module bindings" allowing users to consume Boost as a module could add any value to Boost?
Absolutely it would add value to Boost and to the C++ ecosystem as a whole. We have Steve, Dani, and others who write and implement modules encouraging us to do this while answering our loads of questions. This would help put Boost back on the cutting edge as a technical leader, but it would also be a symbiotic relationship with the aforementioned writers and implementers. Now that I know how it works adding native module support via macros is not overly burdensome: https://github.com/cppalliance/decimal/pull/484. You'll find a few big takeaways in there: 1) A macro to make static constexpr variables inline constexpr 2) A macro to export the functions and classes you want to export 3) A macro to #ifdef out all the standard library headers like Steve talked about I am more than happy to help other authors/maintainers who want to pursue this. I have created: https://github.com/cppalliance/boost2 to explore how we can build and install boost library modules. The end result is hopefully a working demonstration of an import boost2 which contains multiple library modules to ease the concerns of viability. It doesn't contain anything interesting yet, but I will come back with reports of success or failure. Matt