What are the worst parts of D?

[Dicebot via Digitalmars-d]

I am in the mood to complain today so this feels like a good 
moment to post a bit more extended reply here.

There are three big issues that harm D development most in my 
opinion:

1) lack of "vision"

TDPL was an absolutely awesome book because it expained "why?" as 
opposed to "how?". Such insight into language authors rationale 
is incredibly helpful for long-term contribution. Unfortunately, 
it didn't cover all parts of the language and many new things has 
been added since it was out.

Right now I have no idea where the development is headed and what 
to expect from next few releases. I am not speaking about 
wiki.dlang.org/Agenda but about bigger picture. Unexpected focus 
on C++ support, thread about killing auto-decoding, recent ref 
counting proposal - all this stuff comes from language authors 
but does not feel like a strategic additions. It feels like yet 
another random contribution, no different from contribution/idea 
of any other D user.

Anarchy-driven development is pretty cool thing in general but 
only if there is a base, a long-term vision all other 
contributions are built upon. And I think it is primary 
responsibility of language authors to define such as clear as 
possible. It is very difficult task but it simply can't be 
delegated.

2) reliable release base

I think this is most important part of open-source infrastructure 
needed to attract more contributions and something that also 
belongs to the "core team". I understand why Walter was so eager 
to delegate is but right now the truth is that once Andrew has to 
temporarily leave all release process has immediately stalled. 
And finding replacement is not easy - this task is inherently 
ungrateful as it implies spending time and resources on stuff you 
personally don't need at all.

Same applies to versioning - it got considerably better with 
introduction of minor version but it is still far from reasonable 
SemVer and cherry-picking approach still feels like madness.

And current situation where dissapearance of one person has 
completely blocked and releases simply tells everyone "D is still 
terribly immature".

3) lack of field testing

Too many new features get added simply because they look 
theoretically sound. I think it is quite telling that most robust 
parts of D are the ones that got designed based on mistake 
experience of other languages (primarily C++) and most 
innovations tend to fall into collection of hacks stockpiled 
together (something same C++ is infamous for).

I am disturbed when Andrei comes with proposal that possibly 
affects whole damn Phobos (memeory management flags) and asks to 
trust his experience and authority on topic while rejecting 
patterns that are confirmed to be working well in real production 
projects. Don't get me wrong, I don't doubt Andrei authority on 
memory management topic (it is miles ahead of mine at the very 
least) but I simply don't believe any living person in this world 
can design such big change from scratch without some extended 
feedback from real deployed projects.

This is closely related to SemVer topic. I'd love to see D3. And 
D4 soon after. And probably new prime version increase every year 
or two. This allows to tinker with really big changes without 
being concerned about how it will affect your code in next 
release.

Don has been mentioning that Sociomantic is all for breaking the 
code for the greater good and I fully agree with him. But 
introducing such surprise solutions creates a huge risk of either 
sticking with imperfect design and patching it (what we have now) 
or changing same stuff back and forth every basic release (and 
_that_ is bad).