C++20 added modules, a new standardized granularity between "translation unit" and "program" (there's no such thing as "library", DSO, plugin, DLL, etc in the standard, that's a platform ABI thing): https://en.cppreference.com/w/cpp/language/modules

Seeing as not even the std-library is modularized in C++20, there's little that Qt can do, but there are certain aspects that are interesting:

• preprocessor macros are local to modules
• there's the concept of module-public and module-private code, which nicely fits with our "exported"/"non-exported" and _p.h/.h split.

Some open questions follow immediately:

1. how do we deal with the parts of our API that relies on macros (Q_OBJECT, Q_SIGNALS, Q_SLOTS, Q_EMIT, Q_DECLARE_METATYPE, ...)?
2. can we physically lay out our codebase to support modularized as well as traditional builds, or do we need to have Flag Day, where we transition everything from traditional to modules?
3. what's the relationship between "private Qt API" and "module-private"? Qt-private API is used by other Qt libraries, so it cannot be module-private (there doesn't appear to be friend module). Do we care about users of private APIs that may no longer be accessible?
4. ....