Why it took so long is that: (a) C++ is an international standard, has a huge installed base of business- and mission-critical software, probably billions of l

Why it took so long is that: (a) C++ is an international standard, has a huge installed base of business- and mission-critical software, probably billions of lines of code, tens of millions of programmers, and we can't afford to get things wrong (though we still do sometimes). (b) Nobody has built a large, _very_ generic, general purpose, high-performance library, on top of the (also new) C++ concepts language feature before. We were figuring it out as we went. (c) While standardizing this piece, we were also thinking 5 to 10 years down the road and trying to make sure what we were standardizing now would evolve well. For instance, we already know pretty well what using ranges with coroutines will look like (i.e., reactive streams). We already know what other lazy range adaptors we want, and we know they work with the bits we're getting for C++20. We know how to integrate eager adaptors that transform containers and compose. This all needed to be built, tested, and well-understood. As for why it is `std::ranges::sort` instead of `std::sort`, this exercise wasn't just about adding overloads that take ranges instead of iterators. It was also about rigorously specifying in code what the requirements of each algorithm are. For Reasons, we can't just slap new requirements on old algorithms that have been shipping for 20 years. It will break mountains of code. Nobody likes having two `sort` algorithms in two different namespaces. It is preferable to the alternative.