668 – Use of *.di files breaks the order of static module construction

The spec says that "each module is assumed to depend on any
imported modules being statically constructed first" in module.html.
But when I use *.di interface files, the order seems broken.
Here is an example:
//credit goes to http://pc8.2ch.net/test/read.cgi/tech/1158013550/987
------- lib.d -------
bool initialized;
static this(){ initialized = true; } 
------- main.d -------
import lib;
import std.stdio;
void main(){ } 
static this(){ writefln("lib.initialized? ", lib.initialized); } 
> dmd -c -H lib.d // generating lib.di
> dmd main.d lib.obj
> main
lib.initialized? false // wrong
> del lib.di // deleteing b.di
> dmd main.d lib.obj
> main
lib.initialized? true // correct

The likely cause:
-----
urxae@localhost:~/tmp$ cat lib.d
bool initialized;
static this(){ initialized = true; } 
urxae@localhost:~/tmp$ dmd -H -c lib.d
urxae@localhost:~/tmp$ cat lib.di
// D import file generated from 'lib.d'
bool initialized;
-----
The static constructor isn't present in the .di so the compiler doesn't see it when compiling main.d.
Confirmed on dmd-0.177/Linux.

Indeed, when you change lib.di to show the existance of a static constructor:
lib.di
---
// D import file generated from 'lib.d'
bool initialized;
static this();
---
Then it'll work as expected. Confirmed on dmd 1.013.

*** Bug 1278 has been marked as a duplicate of this bug. ***

This bug is blocking the Arc v.2 release. 

Raising severity in accordance with clayasaurus's comment.

Strictly speaking, since there's a work around, it's not a blocker. But it's fairly serious so I'll leave it as is.

I'm using a work-around for now and I am going to release Arc v.2, but I still want this bug fixed! :)
Plus, this bug is high-severity for any DSSS installable software, because any DSSS library that uses static ctors will be broken. 

Fixed in DMD 1.019 and 2.003. Thanks Walter!

I don't think this issue is completely resolved. The compiler now generates a "static this() {}" in the .di file whenever it seems a static ctor in the module. However, the presence of a complete but empty static ctor seems to convince the compiler that they are available, inlinable and empty. In some instances, this causes errors like:
"filename.di(0): variable SOME_VARIABLE missing initializer in static constructor for const variable"
This is preventing the Tango user library from compiling properly on 1.019 and above for Linux/MacOS.
The solution seems to be generating "static this();" rather than the complete "static this() {}".

Please provide a test case.

----
// Header.di
class Thread
{
 final char[] name();
 static const int PRIORITY_MIN;
 static const int PRIORITY_MAX;
 static Thread getThis();
 static this(){}
}
----
// Main.d
private import Header;
class Main
{
 void go()
 {
 char[] threadName = Thread.getThis.name;
 }
}
----
C:\> dmd -c -inline -release Main.d
The crucial bit is to have -inline and -release set. Clearing either of these eliminated the problem.

Fixed in 1.022/2.005