Yes. I can imagine lumping many modules into a single library. My main executable may import all of them somewhere, however I may want to have separate unit test binaries for modules A and B that only import their own module, but link against a lib that has both. And for the sake of argument, let’s assume that both modules have some self-registering objects in dynamic init, and it is important that they both run in both unit tests.
That sounds like it will result in roughly one function call per import statement in the program prior to main. How ABI resilient does this need to be? Could the PMI collect up all imports from all of its interface units and imported partitions to remove duplicates, or do you need to support replacing a single interface partition without recompiling the PMI? Is a TU allowed to omit calling the initializer for one of its imports A if it can see that another import B also has an interface dependency on A, or do you need to be prepared for B to be replaced with a version that doesn’t import A transitively? If some leaf TU doesn’t have any dynamic init and says so in its BMI, do importers still need to call its init function in case it is replaced? If not can this be transitively done for any TU where all interface dependencies have no dynamic init?
Also, is there any way that this could instead be written in some metadata tables showing the direct dependencies and resolved by the linker into a single ordered list of either flat per-TU or per-object initializers for each DSO? That seems a bit better to me than trying to do it pessimistically via function calls.
That optimization would only help for implementation partitions that have their own dynamic init. That seems likely to be enough of an edge case to not be worth microoptimizing for, even if it were valid to do so.