I'm not the GP, but I thought I'd bite.
tldr; It's not perfect, but it's closer than you'd think.
D sounds like a neat language that I'll probably never be able to use. I'm a game developer, and C++ has a native compiler for every machine I would ever need my code to run on
DMD, LDC and GDC (the 3 most popular D compilers) work fine on x86 and x86_64.
LDC supports ARM and PowerPC with some issues. GDC apparently has better support for ARM
as well as an already mature ecosystem (engines, code libraries, sample code, all in C++).
D has very good interop support for C and C++ libraries. There's a significant number of wrapper libraries in dub as well.
In general, C code can be used as is, while C++ libraries often need a wrapper to work around issues like templates.
In fact, C/C++ is pretty much the only option I have if I want my code to be broadly portable.
Yes, C compilers exist for pretty much every architecture in existence, with C++ supported on most of them.
But this is a red herring, because the only instruction sets that really matter to someone in game development are x86, x86_64 and ARM. Whether or not you can compile your code for PIC is completely irrelevant. (That said, LDC uses LLVM for its backend, so it probably has the best chance of supporting unusual architectures.)
It's interesting how a lot of languages don't seem worry too much about backward compatibility, because they want to focus on a clean and better language. Unfortunately, in the real world, there are always massive amounts of legacy code that need to continue to work alongside whatever new whizbang features are introduced, even at the expense of a cleaner or more elegant language.
If I had to give any one reason for C++'s success, it would be the standards committee's stubborn (and in hindsight, wise) refusal to "clean up" the language by removing crufty features and syntax, a lot of which were leftover from C. C++ code from 20 years ago still compiles today mostly unchanged, and that's incredibly important when trying to build up or maintain a large ecosystem. You can see what a huge split it causes in the community when a language breaks compatibility like Python did (2.x vs 3.x), and ultimately, I wonder if it's more damaging than C++'s more conservative approach. As a developer, I'd be hesitant to heavily invest in a language that is more likely to break compatibility and leave me stranded.
Backward compatibility is always an issue with any piece of software. That said, I think there's something to be said for handling breaking changes well as opposed to handling them poorly - anything which creates a rift in the community is obviously an example of the latter.
Python was an example of the that, since it wasn't possible to combine code from old and new versions. While D had a breaking change with D2, there is only one person I am aware of who is still using D1. The standard library from D1 (Tango) was ported to D2, and the syntactic changes were fairly minor and easily remedied.
It's also worth noting that the D1 branch of DMD is still maintained, should you actually need to compile D1 code.
Pretty much every language is going to accumulate cruft over time. Even if D accumulates it at the same rate C++ did, it's relative youth means that it will be much more pleasant to work with, since C++ will always have more. I think the only real way to completely remove all that cruft is to create an entirely new language - no one would have complained about Python 3 if it were marketed as a new language, rather than as a new version with breaking changes (Nimrod is an example of this). This is what D is to C++ - a language with equivalent power that wipes the slate clean.