The similarities are more surface deep once you start learning more about the different features and tools D offers.
Walter Bright did try to make C++ better, remember that D came along after he wrote the Digital Mars C++ compiler.
C++ has also improved in the meantime.
And appearance really only changes when you hit templates. And with D you can't tell (as an outsider) so it just looks like the non templated C++.
So either you work alone, in a small team that appreciates modern safe C++ (including Core guidelines), and enjoy C++, or you are faced to deal with all idiocrasies and unsafety issues from the past.
Not every project can be written 100% in this style, but the problem is very often programmers trying to mimick C++, e.g. doing object oriented fine-grained initialization/destruction stuff in C.
As Google, Microsoft, Apple, Amazon have been reporting in multiple occasions, the problem goes beyond programmers trying to mimick C++.
To the point that future Android versions will require hardware memory tagging enabled on ARM devices.
If you're actually going to look at it, I just want to make clear that I've never fuzzed it or anything, beyond running valgrind maybe twice (should be mentioned in the git log). And on the functional side, I don't even know what state this project is in. I think I lost interest in it when I needed to implement yet another way to encode x86-64 instructions, since having both floats and doubles is a requirement to run interesting things with OpenGL.
Let me know what problems you find!
Now tell me why every OOP codebase I look at has this problem. ;-)
The reason is the second "O" in OOP. Trying to switch on the type of a thing, where every thing has only one type (ignoring inheritance which is another problem, not a solution), means that people will put all sorts of unrelated things in one place.