To be honest, if that happened I'd be 100% on board. My issue is combinatoric complexity, not a new way to do things. I'm not frustrated that we have constexpr; I'm frustrated I now have to worry about how it interacts with macros and namespaces and lifetimes and oh what if the values are templates and so on.
Each feature adds superlinear cost to understanding the language and the code you're reading.
It does, because many delivery projects chose languages based on the product SDKs, so if it isn't in the box, they don't come into the discussion at all.
Also in the meantime, most of the cool stuff in D is showing up on the languages that come on those SDKs (C++, Java, C#), weakening the argument to look outside of SDK supported languages.
Doesn't matter if D had it first, or if it has a better implementation, worse is better, when ecosystem, tooling, IDE and technical support are part of the equation.
All of my many products are commercial. I mostly have freedom to choose language. But I am also my own software development company and I have never felt brave enough to leave my client/s with the mountain of D code and no one to help after I went to develop next product somewhere else. This is very unfortunate.
Each feature adds superlinear cost to understanding the language and the code you're reading.