For me as a high level application developer, I liked C but felt that it needed a rational module system, generics and structural types. The addition of methods on structs would be nice too (no need for inheritance).
The only reason I thought about it is because I have been trying (and failing) to contribute to open source Linux projects - which are practically all written in C and the C++ projects are impossible to read.
Due to my lack of experience, I definitely have no business criticising the language design of C or C++ haha but it's fun to talk about.
The issues I faced with C++ were that it has too many features. I feel that makes it difficult to carry experience in one project to another due to the variety in styles afforded by that design choice.
I once saw a C++ tutorial that rewrote a verbose for loop into a functional chain and it was practically unreadable for anyone lacking considerable C++ knowledge.
I'm also not a big fan of the way the module system in C++ works (similarly to C#, Java, Rust) where you import a namespace and then things are just available or extended.
Probably an unpopular opinion but, when evaluating the language semantics alone, I quite like the approach TypeScript takes to modules. You import a "thing" from a "relative filepath" explicitly and there is no ambiguity as to its origin (even when just groking a file in a low-tech text editor). For me it makes the process of tracing and understanding circuits easier than sorta guessing which namespace a function or method comes from. This also makes it easier for compilers to optimise binaries as they can statically determine what code is used, excluding unused code from a build.
I guess I could probably say the build system for C is difficult to grasp. In the high level world, I'm used to simply saying "compiler build main.xyz" - where C has makefiles, configure scripts and I find it a bit much.
Not just too many. But inconsistent ones, hard to use ones and badly designed ones. std::unordered_map anyone? The iterator-based APIs are just cumbersome and error-prone to use, etc... it's really easy to shoot yourself in the foot by forgetting to explicitly implement specific constructors, or by passing the wrong iterator (like begin() vs end()) to an STL template.
The C# specification isn't significantly smaller than the C++ one (can't check the exact length right now) but the language is still much easier to understand, even if it has really hairy corner-cases like the difference between readonly fields and normal fields' generated IL or the logic for defensive copies. Most programmers don't have to care, and even if you do, it's not a nightmare to test or experiment with.
In C++, I kind of feel I'm trying to squeeze water out of a stone. And even with the huge standard library, basic things are missing from it like a string startswith.
The only reason I thought about it is because I have been trying (and failing) to contribute to open source Linux projects - which are practically all written in C and the C++ projects are impossible to read.