You're getting downvoted because your argument is cosmetic, egotistical, and useless. Can you give an objective separation between design flaws and engineering details? One that has zero ambiguity: if I give 100 engineers your criteria and then ask them to categorize 100 different points against it, would give exactly the same results? And would that distinction actually correlate to a historical analysis of programming languages' effects on software project success metrics?
No, because the entire distinction falls apart pretty quickly into "shit I like to discuss and care about" and "shit I don't care about and don't want to talk about."
Systems programming lives and dies by the details you want to ignore. The economics of large software production are mildly affected by language design. But weaknesses there are easily overcome with engineering practices and additional tooling. Almost every complaint about C++ safety I've ever heard hasn't been a problem for me for decades, because I know what libraries, practices, and tools solve those problems. But I've yet to work with another language - and I've programmed in a shit-ton of languages - that gets out of the way as well as C++ when I want to systems-program. Even C. C is strictly lower level, but its lack of abstraction facilities gets in the way more than some of the modern numerical-type-safety stuff of C++ does.