> what's stopping a package manager from being added? ...
> It just startles me that there isn't a single,
> consolidated package manager to have rolled out of the
> millions of work-hours that have gone into C++ projects.
>
> It's possibly the single biggest criticism of the
> language that I felt wasn't tackled at all.
As far as the standard committee: "creating tools" is outside the scope of "defining a language and its standard library." As far as the "millions of work-hours that have gone into C++ projects," it's probably a combination of nobody's come up with a package manager that satisfies enough programmers and nobody's been willing to spend the extra time to create such a tool. It's hard enough to ship code on time.
> There is a complete lack of consensus. In trying to
> accommodate everything and anything, C++ has in my
> experience overshot the mark.
It's certainly true that projects that try to take full advantage of C++'s flexibility end up collapsing. Projects generally shouldn't allow "everything and anything" in the code base. And many of the design principles that the committee follows should probably not be applied to software projects in general.
But the language has to satisfy more than your project, or more than the average project that programmers believe exists but can't agree on what it is. I've been writing C++ code professionally for years, and while I know how to, I haven't shipped any GUI code. I did write a gtkmm-based stopwatch to help my son with an elementary school science project (because I thought it was more fun to do that than to buy a stopwatch at the local sporting goods store). But professionally I've only written code for back end web services. I know I'm not the average C++ programmer people imagine, but I'm not sure if the average C++ programmer is writing desktop GUI software, or iPhone software, or libraries that will be called from Java, C# or some other language via SWIG. I know they aren't the average C++ programmers, but I do know some people write C++ to run on supercomputers (I used to work with one of them).
Regarding a package manager specifically: I personally have been happy to use RPM on my personal Linux system to manage packages. I wouldn't expect people to use RPM on a BSD or Apple system. I'm not sure that we need a special package manager just for C++ libraries. I miss anything like RPM when developing on Windows (edit: another comment mentions NuGet: I'll try it, thanks!). If you write something for Windows, I'll buy a copy.
My web services interact with efficient number crunching libraries written in C++. In my case, I don't need things to be as efficient as possible, but others do. I know Dan Bernstein believes the way to get super-efficient libraries is to use different implementations to take advantage of CPU-specific features ( http://www.tedunangst.com/flak/post/some-gripes-about-nacl ), but this makes package management much harder (at least without function multiversioning -- https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Function-Multiv... -- which isn't required by the standard). Should the committee tell Bernstein he's wrong? Or encourage compiler writers to ship with tools that Bernstein and others have no use for? How should the package manager handle a case where a library could work on my platform, but nobody's compiled it for me yet? What about platforms where the ABI isn't completely nailed down yet?
You have identified a real shortcoming in C++ development. There isn't an easy answer. But, seriously, if you write one I'll be sure to send you some money.