Of course WG21 could have simply accepted the library after it went through years of development and reviews, rather than trying to "fix" it. This is precisely why WG21 should not be involved in innovation and design, because then acceptance becomes a matter of opinion and politics, rather than a simple acknowledgement of an interface that is already successful.
Like Boost, they declare changes which must be made before acceptance. For some features e.g. Coroutines, it ends up being an awful lot of discussion but ultimately very few actual changes other than naming. For others e.g. Filesystem, probably Networking, it becomes how long is a piece of string. Back when Gor started down the standards route for Coroutines, I remember warning him over a burger on a park bench in Aspen just how long a piece of string he could end up upon. He ended up proving me wrong, I am glad to say, just seven years approx start to finish. But it looked at the time to be a decade plus effort to reach consensus for his proposal. For any reasonably disruptive change, you've got to sign on to investing a decade plus of your life to reach standards fruition. Given that we all get maybe thirty to forty years of professional career, that's a very big claim on your productive years.
I'd echo Eric's sentiments on this completely. I don't have it in me to ever get a fundamentals library into Boost again. Besides, I'd likely end up getting divorced and my children no longer speaking to me. It's not worth it, personally speaking.
You leave out the other possibility, to leave the library out of the standard, where most libraries, including good libraries, belong.
The same argument would then apply to Boost by this logic. I'm not sure that I agree with that. The usual counterargument to standardising ever more libraries generally involves a decent centralised package ecosystem for C++, and sure, I get that that would avoid much over-eager standardisation. However Python has world class centralised package management (albeit with a few forks), yet in many people's opinion continues to aggregate too much inferior functionality into its standard library given the extremely high quality of substitutes in its package repos. In particular, some people feel that an inferior library gets into Python's standard library, when a much superior alternative does not. And that's because the inferior library had a champion, and the superior library did not. Ultimately it comes down to committee perception of champions. If someone is willing to champion a library into the standard, in C++ and Python it generally tends to happen eventually given enough application of will by the champion. The people behind the core standard essentially assume that those motivated enough to champion a proposal for as many years/decades as needed deserve to eventually win, irrespective of the fundamental utility of the standard library proposal. Contrast that with C, where the default answer to proposals for new library features is "no, unless you can *prove* its utter necessity for the survival of the language/ecosystem". The former attitude invites large committees, and scalability problems with sheer numbers. The latter attitude dissuades people such that WG14 attendance is approx 20-30 people nowadays, down from 60+ plus a decade ago. The correct attitude is somewhere in between these two approaches. But it's very hard to aim down the middle. I've sat in WG21 watching a library proposal which I personally felt didn't add enough value to be worth the committee time to pass it. But equally, it's not a bad proposal, I personally like the proposer, and nobody else in the room objects because they're all probably thinking the same as me. So it goes through, and displaces time which would have have been more productively spent elsewhere. Personally speaking, I would prefer to have problems of scalability due to growth and numbers rather than problems of lack of enthusiasm. So I vote for what WG21 is doing, rather than what WG14 is doing. Ultimately ISO SC22 (Programming languages) is 99.9% volunteer-led, so you've got to do whatever keeps bringing in the volunteers. If that means over-standardisation in order to keep them coming, I think that's not a terrible tradeoff given the alternative: people just stop caring to bother at all. Niall