Also, if my compiler allows me to shuffle the initialization order of data members. 

For me, that is a strong guarantee that it will catch the following case and process it without error:

Given the struct: base and derived above,

struct mostDerived: public derived

{

    int a;

    double d;

    mostDerived (): d(3.14), derived(), a(123){}

};

So logically,  the compiler should help me here and make sure that this constructor produce correct code, right?

Otherwise i need always to compile my constructor myself before my compiler does it. Which is not programming for me.

So my proposal,  or suggestion,  is relaxing this ordering rule on data member initialization. 

But if this flexibility is not desired, and ppl are content with what they have, then it's ok.

I believe it's generally considered important to destruct objects in the inverse order of construction. If you don't believe that is important, your position is more understandable.

Keep in mind that the constructor(s) and destructors may be defined in different translation units. The only chance they have to agree on the initialization order is via the class definition (i.e. in the shared header file). In theory, you could define a different order in the class definition (there have been proposals to do this by controlling layout separate from declaration order).