Wrong order of shared static dtors

[Marco Leise via Digitalmars-d]

I know the runtime is supposed to work it all out, call
thread module dtors, then shared dtors and then terminate.

But now I have a case where it is broken and I don't know if
we expect the runtime to figure it out, especially when it
comes to separate compilation and such. Basically on one end
I have a singleton template that uses a `shared static ~this()`
to destroy the object. On the other end I have a global list
of reference counted resources, also heavily templated and
relying on a `shared static ~this()` to free the memory
associated with the ref counts etc.
When I build something new from these parts, like a singleton
object that contains on of these ref counted resources, the
runtime is unable to figure out that it has to destroy the
singleton (and its resource with it), before it can call the
destructor of the resource list. For now I just wrote
`import Lib.Sys.Resource;` into the singleton destructor
(i.e. every singleton imports it, whether it needs it or not),
but that doesn't scale obviously.

Should the runtime be able to reliably figure out even such
tough cases? The alternative, disallowing static dtors in
templates isn't appealing.

Out of curiosity: What module do templated static dtors belong
to anyways. And how does that effect when they are called?

-- 
Marco