What monsters put compile-time programming over concurrency and pattern matching?
Compile-time programming is a very powerful feature of C++ that does not have an equivalent in other systems languages. It is commonly used to effect several types of compile-time verification of code design and safety that would be difficult to do any other way, in addition to its more obvious use case for effecting relatively complex performance optimization algorithmically. The ability to algorithmically generate almost arbitrarily complex types during compilation that are fit to purpose is an extremely useful feature for fast, high-reliability code and used pervasively in modern C++ as the facility has become more expressive. Filling some of the last remaining holes in its expressiveness would be high-value novel capability. Think of it as a hardcore safety feature.
You can put me in the camp that adding more support for concurrency in the language beyond a feature like coroutines (in C++20) and the existing primitives is not that useful. It would have the same issue as STL containers, where there simply isn't enough control of the implementation details for them to be used for many applications C++ is used for, so most concurrency infrastructure will be purpose-built anyway.
Pattern matching functionality can already be effected in many cases, albeit quite ugly. This would be more syntactic sugar than new capability, so I can understand why it isn't prioritized as much.
Yes, C++ compile time capabilities are powerful, but they aren't by all means the only game in town.
Some applications that are above the OS and device drivers, such as database engines, are clearly in the domain of systems applications because it is not possible to create a competent implementation without the control a systems language provides. Even for relatively abstract high-level software like distributed systems, strict control of scheduling is required for consistently robust throughput and behavior. Some key algorithms only work in real systems if resource management and concurrent operation sequencing is inexpensively deterministic. For some other applications, the only real benefit of a systems language would be for performance engineering purposes, which may not be a practical priority.
The "managed language" litmus test is quite good in my opinion, and almost definitional.
As somebody who has used threads a lot and written code in kernel mode etc. something about this scratches me the wrong way.
The traditional concurrency toolkit has some issues. Being experienced with them can make you somewhat jaded against them. In particular, the standard way to solve problems in that mode of thinking is to introduce locks, and experienced people know all the problems that locks have, and that the "solution" is harmful in the extreme.
So it is acceptable for such a programmer to want more options, standardized. I would even argue that this is more important than introducing std::mutex, std::thread, or std::atomic, because you can say that in the pre-C++11 era nonportable interfaces like pthreads or win32 were already working OK for people that chose to use them.
nowadays I mostly see lock-free queues and message passing across threads, it's trivial to do with a few nice libraries
There's tons of reasons why this could be this way; and it shows why creating these kinds of things is just hard.