When I was in college in the 90s, templates were new and had iffy support. In the 2000s, STL was still problematic. I remember the Microsoft Compiler spitting out error messages on STL types that were so long the compiler couldn’t handle the string length and truncated the error message so you couldn’t see what the problem was. In the late 00s and early 10s I worked in games, we wanted stability and for the code to be as non-tricky as possible (for example by banning use of exceptions, STL containers, and most casual heap allocation, among other things.) So we used older compilers by choice. My current job publishes an SDK and APIs that people have been using for many years, they need to be backward compatible and we can’t impose recent language features on our users because not everyone uses them, we have to stick to features that compile everywhere, so I still see lots of C++{11,14,17}.

The problem is that with the new wind C++ got with C++11, its role in GCC and LLVM, and domains like HPC, HFT, GPGPU, WG21 got up to 300 something members, everyone wanting to leave their name on a C++ standard, many proposing features in PDF form only.

And since in ISO driven languages, what gets into a standard, does so by votes, not technical implementation merit, it is about doing a proper campaign to get the bases to vote for your feature, while being persistent enough to keep the process going. Some features have more than 20 revisions on their proposal.

The core of reflection should be in C++26, yes. In my understanding, there's more to do after that as well. We'll see when the final meeting is done.

Gives what you wished for. It's functional, though (among other things). Unlike most lisps, (dependently) typed. But hey, available at compile-time.

At no point were lambdas single return statement. You might be confusing it with some other language feature. Or language.

That is more a dynamic monkey patching programming language kind of thing.