DIP66 has been approved contingent to a few amendments as noted

[Joseph Rushton Wakeling via Digitalmars-d]

On 24/12/14 15:27, eles via Digitalmars-d wrote:
> D2 is still looking for the best design. D1 has one, is not as good, but is a
> safer default.

Honestly, developing in D1, I personally feel that this is not so much a stable 
version as a frozen snapshot of a still-evolving language.  There are just too 
many idiosyncrasies and inconsistencies in its design (for example, the way in 
which dynamic/static/associative arrays behave).

Now, that said, in practice D1 does feel for the most part very much like a 
subset of D2 features; you could code a new project in D2, using the same design 
principles, and have pretty much identical results.  So it's entirely fair to 
see a D success story here.

With more historical resources, it might have been sane or possible to backport 
some of the relevant breaking changes -- that is, to have a D1.5 with the same 
reduced feature set but with the inconsistencies and bad design decisions ironed 
out -- but now that D2 has reached its current state, it doesn't seem worth it 
to me.  D2 may still be evolving, but it's stable _enough_, and with good change 
management (e.g. the -dip flag as discussed here) there's nothing on a 
_language_ basis that seems other than an improvement (Dicebot may have some 
counter-examples to hand, but off the top of my head, I can't think of any:-).

I suppose that we could, today, divide D2 into a guaranteed stable subset and a 
wider range of features whose final design is still up for discussion, but even 
that seems non-trivial: cf. the kerfuffle over whether class methods should be 
virtual or final by default.  (And no, please don't take this as a reason to 
re-open that discussion.)

The simple, straightforward fact is that it's hard to upgrade a large codebase 
with high performance requirements.  That's not a judgement on D2 as a 
production-ready language.