John Maddock via Boost
1) Is there any existing best practice we should follow yet?
AFAIC, there is no practical, real-world experience using C++20 modules in a substantial codebase. In fact, out of the big three compilers, only MSVC has usable C++20 modules implementation (or claims to have; last time I tried it, which was admittedly a while ago, it wasn't).
2) Can we share code content effectively between headers and modules? And by modules I mean "proper" ones: we should be able to write "import boost.whatever;" rather than importing a header.
As an experiment, I've tried to do this using the preprocessor in a smallish library and it degenerated into an unmaintainable mess faster than I expected. IMO, the two viable options are: 1. Drop headers and focus on modules only. 2. Find an automated way (likely by the build system) to translate (sensibly written) module interfaces to headers. I have some ideas on this in the context of build2. Note that I don't consider the "just re-export the header unit" approach "modularization" since you don't really use any of modules mechanisms.
8) Is there demand for this?
I think there will be if/when C++20 modules are well supported by the compilers. However, modularizing Boost will be a big (and largely thankless) undertaking. Perhaps the more realistic first step would be to make sure public Boost headers are importable.