Nearly once per year, a blocking bug sneaks into the compiler and needs to be worked-around (crashes on invalid code are easy to avoid ; sometimes, it's a little more tricky, but we've never been blocked for more than 1 day). The maintainers are very active, though, and it's generally quickly fixed, provided that I report the bug myself. There's also been some friction when it came to cross-compilation (definitely doable, but not as easy at "apt install mingw-gcc").
In the team, the adoption went well ; coming from C++, switching to D feels natural. The syntax is more concise and consistent than C++14 syntax. The standard library handles so much stuff (md5, sending emails, command line parsing, filesystem, process creation) that most of our projects don't depend on any other external library (nor do they depend on any OS-specific stuff). The fact that all variables are initialized by default makes it hard to have non-deterministic behaviour ; and the fact that the "buffer" abstraction (aka "Span"/"Slice"/"string_view"/"ptr+len") is in the language makes it really easy to write code which is concise and secure.
C++ has been slowly catching up since 2011, however, why wait?
Learning D for real is as involved as any other language, but what people remark first is the low mental overhead and how absurdly practical it is.
Advantages I see would be: fast to edit, compile, and run. Non-controversial syntax, focus on power, and the fact you kind of already know it.
I mostly work with gdc from GNU/Linux, and basically, everything that works with g++ works with gdc. More precisely, I use, on a daily basis: - vim + ctags (editor + symbol lookup) - gdb (debugger) - gcov (code coverage) - valgrind (mostly callgrind (call-graph) and massif (memory profiler)) - oprofile (cpu profiler)
Unfortunately there's no ccache equivalent yet, and I'm missing it.
For the Windows people, there's VisualD, which basically is the integration in Visual Studio. At this point, you have an IDE and a debugger (I don't know about code completion).
There's also a build-tool (with package-managing abilities), called "dub" ; that handles fetching and building external dependencies (in the vein of npm).
Someone should do a Language Server Protocol (http://langserver.org/) implementation for D - that's clearly the way forward. Right now this will give you VSCode, Eclipse and NeoVim, with regular Vim and Emacs on the way.
VSCode also has something similar for debugging (https://code.visualstudio.com/docs/extensionAPI/api-debuggin...), but it hasn't been standardized in a similar fashion (yet?).
One thing D and Nim are lacking is adoption by a large company, and I feel that's partly what's keeping them behind Go and Rust.
If you're going to use it, I highly recommend the D Programming Language (book). It's extremely well written, and remains once of my favourite technical books.