My hot take: when D intends to compete with C++, having an opt-out GC is a deadly disadvantage.
It is difficult to prove to the performance-oriented people that GC'ed languages can be performant, and years of JVM stop-the-world GC didn't help to improve the reputation of GCs either.
Even though D has @nogc, non-D programmers would probably have serious reservations as to whether the ecosystem is split between GCed and GCless, and how much that split would affect them and their project.
IMO, Rust did it quite right in this regard by making GC opt-in (with rust-gc) - although borrow checking is an imperfect way of doing safe memory management (eg. cyclic references), the fact that it attempts to be a "safer C++ at no runtime cost" certainly has pulled some people over.
The whole GC thing is a non-issue to a pragmatic programmer. D's GC is not going to pop out and smite your program. It's just one of many methods of dealing with memory that D provides.
The "serious reservations" is simply unfamiliarity.
The GC has uses where it shines. Allocating data structures that last the lifetime of the program instance. Enabling data allocation during Compile Time Function Execution. Scripting programs.
Borrow checking has its costs, too. Some data structures won't work with it. Sometimes to conform to it means allocating an extra copy. Some code has to be marked as unsafe.
This is a gross misrepresentation. With D you must opt-out and be cognizant of libs they may or may not require GC.
> Competing standard libraries are thing in the past after the Tango project has been abandoned.
We are discussing why D failed adoption where the history and past are INCREDIBLY important factors.
So really, what are you talking about?