> To frame the question in another way: Is the implementation required
> to invoke the global static initializers of internal partitions that
> are never imported anywhere?
>
> My answer would be "no". The reasoning being the same as why we don't
> add all objects with static initialization from library archives if
> they don't resolve any undefined symbol in the program.

I think it's not actually relevant whether they're imported anywhere. The question is whether that implementation partition is one of the translation units of the program ([basic.link]/1). (Your point is that we do not consider membership in an archive to be a sufficient condition for being one such translation unit.) Of course, since importing a translation unit requires that it be part of the program, it only makes sense to have the linker incorporate an object file for an implementation partition based on an import somewhere even if it is not explicitly named or otherwise needed to satisfy an undefined symbol reference.

The converse does not hold, so I would not expect the behavior of a well-formed program that includes an implementation partition T by virtue of explicit nomination to the linker to change if an import of T is introduced in an otherwise empty translation unit. If the importer is non-empty, of course, [basic.start.dynamic]/2.2 may cause the import to change the order of non-local initialization, as well as suppressing the freedom otherwise afforded by /5 to ignore entirely a translation unit that contains just an unused variable with side effects in its initializer.

Davis