[1] I really, really, really, really wish Boost would expunge the undermaintained libraries already. They waste productivity for so many people out there who think they're using a Boost quality library, when they're not, and get badly burned for it.
Could you be more specific? Which libraries need attention?
Oh I've been quite specific in the past. I've given up trying.
If you want to reply directly I can work with the CMT to assess. Issues like this need to be brought up on the mailing list if folks thing something is being neglected.
A long time ago I made a list of Boost libraries ordered by the number of open, unresolved issues weighted by their age squared. The library which comes top of that list nobody would say isn't maintained, but the next few are very likely candidates for expunge. They don't have a maintainer, have long standing severe bugs which ruin productivity for their users, and worst of all, *do not advertise their low quality* in their documentation. They are also not core libraries, so removing them won't break other Boost libraries. Me personally, for each library without a maintainer I'd print a box at the top of every page in their documentation showing how many open bugs there are, and the average age of that open bug. Plus a wee note asking for somebody to step up to take over as maintainer. That means Boost stops lying to its user base wrt to its patchy quality.
We do have some procedures for dealing with this. I know we need to find new homes for libraries that Beman was maintaining.
Somebody, not me, ought to make a Boost.Filesystem v4 written using LLFIO. It would be an enormous improvement on STL <filesystem>, and would be the basis for the future reform of STL <filesystem>, which has a lot of problems.
We're removing Boost.Signals(v1) in 1.69.0. It was deprecated for.. a long time. (too long...)
My personal biggest bugbear is Boost.Iostreams. It should have been deprecated years ago. And I keep answering questions by perplexed users on StackOverflow who have sunk significant costs into adopting that library, and then find out to their horrible surprise that their work must be completely discarded and they have to start again with a non-fundamentally-broken alternative. Thankfully, we are on course to be able to offer in the C++ standard library a somewhat complete alternative to Boost.Iostreams by C++ 23, god willing. Niall