I find it odd how all the innovations in getting broadly useful algorithms into a standard library happened in C++ but not C.

It almost feels like the people who keep churning out new standards of C just gave up and decided that part of it couldn't be improved any further.

My guess: in C++ it's templated and header-only, which means optimized hash table code gets generated for the types you use it for, and you don't pay for it in binary size when you don't use it. In C you get stuff like qsort which is a single symbol in the libc binary, to which you have to pass a comparison function as a pointer, which is awkward and slow because it isn't inlined (unless you do link-time optimization, do people really?).

Eh. No. C is meant to be lightweight. Many people, including pro-C++ individuals, agree the C++ standard library is way beyond bloated.

Let me preface this comment by mentioning that I've not written a single line of C in my time as a software engineer.

Why would C cease to be lightweight if it added default libraries with lots of capability?

I think this kind of library should generally be in user space, not standard lib as "standard lib is where libraries go to die" (they can't really be modified after because of backward compatibility) but I'm confused about your argument.

I've certainly run into this a non-trivial amount of times myself. It's the one thing I'm really missing in C.

I frankly don't understand why projects [*] are still written in pure C. With the exception of a few edge cases, C is pretty much a subset of C++, so you can easily write code that's 100% C, except for when useful data structures from the STL are required. In this specific case, what is the disadvantage of writing C code that pulls in std::unordered_map when a hash table is needed, but otherwise does not use any other C++ language features?

[*] aside from those targeting niche, embedded systems for which C++ is unavailable