Go is targeted for developers that can move out of C in their use cases.
D is targeted for developers that can move out of C++ in their use cases.
I've always much preferred C style to C++/D/Rust based mainly on readability and how small the language felt. I completely agree though that Go has given me this similar feeling - to me it really is a modern C. That said, I'm not sure how many C devs are going to like the bounds put in place by Go, or the mandatory GC.
I am, admittedly, a big fan of go also. For me, it has taken from both C and Python use cases, which I think says a lot about its versatility.
The D statement may be accurate, I've never done anything with D and only minimal brush ins with C++ - but to my untrained eyes, they seem pretty similar.
However, I quickly became disappointed with Go's spartan design, given my broad experience across languages and paradigms.
That is why somehow I feel it is more indicated for C developers, that could live with a GC enabled language.
As they would mostly getting type safety and a few more features, whereas developers from other languages are mostly giving away features.
D also owes more of its ancestry to C++, while Rust takes a lot of its inspiration from the ML family of languages.
Both languages are gunning to appeal to C++ programmers, and they're both worthy in this regard depending on your use case. The C++ pie is more than big enough to let both languages thrive independently (and their underlying philosophies are different enough that I expect very little overlap between their communities).
That doesn't mean that it's stable, it's just that we do know what it looks like.
(Disclaimer: I work on Rust, among other things.)