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.
This is possible and there's more than one way to do that. Both require an additional so-called module interface unit that defines the interface of a module (at least one per library).
Option 1 is to export the public names through exported using-declarations in the purview of the module. Option 2 is a kind of preprocessor gymnastics in the existing headers to declare public names as exported when compiled from within the module interface unit. I've done that in the popular {fmt} library which is a so-called 'dual-mode library' (a term coined by me to describe the capability of a library to be consumed as both a module and a traditional header) Excellent, so it can be done, that was exactly what I was thinking of. Do you have any feel for whether this improves performance and/or gets much use?
3) What directory structure should we all be using for module definition files?
Module interface units are just sources that require a special invocation at compile time. Sure, but it's helpful for folks to know where to find stuff, we could just put them under /src, but since they're completely orthogonal to regular source files I would tend to opt for a separate directory.
4) Do we have Boost.Build support yet?
None afaik.
5) What file extensions should we be using?
Compiler vary here (msvc: .ixx, gcc: .cpp, clang: .cppm). SG15 seems to slowly converge towards .ixx. At least this is what I see in the SG15 meetings.
6) I presume we would all use the boost.libraryname and boost.libraryname.sub_feature naming convention with boost.libraryname pulling in the whole library?
A perfect situation for bikeshedding...
Green please, they're always green ;)
7) Does anyone have a handle on the current state of std library modularization?
It is voted into the C++23 draft. Microsoft has an experimental implementation for ages, Stephan (STL) has this currently on his plate and is actively working on it. I expect this to see this Real Soon Now in msvc.
Good!
8) Is there demand for this?
I've tried to get a handle on a modularized Boost in the past year but its current implementation seems to be quite hostile towards modules.
And no doubt lots of other things I haven't thought of.
There are a few pitfalls and things to consider if you want to use existing code in the modules world. I point out some of them in my talks last year (NDC, CppCon, Meeting C++). The last one from Meeting C++ 2021, "A (Short) Tour of C++20 Modules" is the most comprehensive and polished one, slides can be found on the Meeting C++ website. I gave a company training on topic that last week because the developers there are considering switching over to modules and were asking about the way forward, considerations to be taken into account, the state of the ecosystem, and all of my experiences in our daily use of modules in our company codebase.
Many thanks, John.