Allow me to be the devil's advocate. > When I look at C++14 and later I can't help but throw my hands up, laugh and think who, except for a small circle of lan

Allow me to be the devil's advocate. > When I look at C++14 and later I can't help but throw my hands up, laugh and think who, except for a small circle of language academics, actually believes that all this new template crap syntax actually helps developers? I do. There are a lot of features introduced since C++11 that make my life much easier. Sure, it's always scary to have to learn new things, but once you get over that hump, you start to see the benefits. Concepts and constexpr cut down on the template boilerplate crap a lot. Being able to use the auto keyword in more contexts means less repetition. Modules get rid of the ugly hack that is the preprocessor. std::span means I don't constantly have to pass around a pointer and length, or create a dedicated struct to encapsulate pointer+length. Sure, there are some more obscure features whose usefulness are questionable, but for a design-by-committee language, they're doing a slow but sure job of moving past the language's old warts. > In reality what's going to happen is that inside every organization a group of developers with good intentions, a lack of experience and too much time will learn it all and then feel the urge to now "put their new knowledge to improve the codebase", which generally just puts everyone else in pain and accomplishes exactly nothing. Feature adoption doesn't happen overnight. Remember, we're talking about a decades-old language burdened by backwards compatibility - it took a long time for people to migrate from supporting C++03 to dropping it in favor of C++11. Give it five or ten years, and I reckon you'll see people make use of C++17 and C++20 in much greater numbers. > Waiting for Cross-Platform standardized SIMD vector datatypes No argument there. That said, all mainstream compilers already have "immintrin.h" for x64 and "arm_neon.h" for ARM, and using them isn't particularly difficult. > Using nonstandard extensions, libraries or home-baked solutions to run computations in parallel on many cores or on different processors than the CPU Are you aware that std::thread has existed since C++11, and std::jthread and coroutines are in C++20? > Debugging cross-platform code using couts, cerrs and printfs This is a programmer problem, not a language problem. gdb exists, lldb exists, the Visual Studio debugger exists, and they're not particularly hard to pick up and use - if you're still using print statements to figure out why your application is crashing, that's on you. > Forced to use boost for even quite elementary operations on std::strings std::string is an RAII-managed bag of bytes. What kind of operations are you looking for? Stuff like concatenation and replacement can already be done in C++11 with std::string and std::regex. If you want to do lexical operations, like case conversion or glyph counting, then an encoding-aware library is a better solution.