Many people are not looking for a "better C++", in the land of C++ it seems "better" means "more features", and some of us are not interested in more features, but in a better selection of fewer useful features.
See Rob Pike's essay on this very topic and the design of Go:
The goals of C++ are performance and abstraction and I do not know any language which beats it in both points.
I appreciate "small" languages, which can do a lot with a little core and abstraction mechanisms (Scheme,Smalltalk,...). However, for maximum performance, you need a good compiler, which understands and optimizes your abstractions. In the case of Lisp, whoever writes the macros is also responsible for optimizing them. Unfortunately, this requires application programmers to be also good in writing compilers.
C++ certainly has deficiencies, which cannot be fixed without completely breaking backwards compatibility. Rob Pike probably has them all included in the list you linked to. E.g. irregular syntax and header files.
In my opinion D has mostly fixed those conceptual issues. Unfortunately, D is not mature [0] and development is slow. While D is certainly not the final word in language design, I consider it the only serious competitor to C++.
>Many people are not looking for a "better C++", in the land of C++ it seems "better" means "more features", and some of us are not interested in more features, but in a better selection of fewer useful features.
yes, i'm looking forward eagerly to rust, especially because it has algebraic datatypes and pattern matching. not sure how it will stack up to D speedwise, though.
What in particular are you not sure about in terms of performance? With the exception of segmented stacks, Rust adheres to the zero-cost principle just as C++ does.
not any expensive-looking features per se, simply that from looking at new languages, especially the ones with powerful features, speed is the hardest and usually the last thing to be achieved. i think ats is the only exception i've seen to that.