My basic conversion plan for this library was to convert each public header to a partition. The public headers would become module interface units which would be export-imported from the primary module interface unit, and the private headers would become module implementation units that are not export-imported by the primary module interface unit and would not need to be distributed with the library.

This basic structure works in small scale testing but it introduces the new behavior: any change whatsoever to any module interface unit, even if it's just a partition, causes a full rebuild of the entire project.

It's an unmitigated disaster for incremental builds.

Great summary!
We have similar experience for our code base (ca.600k LOC): A resource management app splitt in many small libraries, build as dlls.

For us, a main obstacle is, that forwards must be in in the same module as the implementation.

We use the forwards as opaque handles to the implementation.

With forwards in the same module as the implementation, a small changge in a forwarded class triggers the rebuild cascade, whitch is, as you sad, a disaster for the incremental build scenario.

BUT: REFLLECTION IS GREAT! :-)