if you were writing a new candidate Boost library with C++11 as its baseline, would you strive to use std components rather than their Boost counterparts, no matter how good the latter are? I would say you would.
I would not. As a user (either in-Boost or external) I would choose the library that is technically better. Boost.Regex is actually a very good example of such, as it is considerably faster than at least some popular std::regex implementations. There are other examples where Boost equivalents are technically better in one regard or another than the standard counterparts. I think this is the point with using any dependencies: Is the added value (in performance, features, ...) worth the cost (compile time increase, maintaining compatibility, ...) And as stated above: Using a stdlib part is not considered a dependency by most. Next, I disagree with the idea that a library could be "not allowed to progress". Why block further improvements and extensions? Take Boost.Atomic or Boost.FileSystem, for example. These libraries are not equivalent to the standard counterparts, and offer extensions that are useful in practice and cannot be efficiently implemented "on top" of the standard components. What would be the point of a Boost.Atomic v2 if it had to reimplement Boost.Atomic? We are spreading our time thin as it is already.
The above examples are not an exception. I think, almost every library that was adopted by the standard is not equivalent to the standard component. Some of them have continued to evolve since adoption, and results of this evolution may be adopted by the standard in the future. I see no point in creating new versions of such libraries on each iteration of such adoption.
There is no reason. The point of the proposal is to reduce dependencies and hence "bloat" most users complain about. Boost.Atomic can stay Boost03 and be fine. If it has features the std variant does not have AND does not use other Boost libraries subsumed by the std then it would even be considered part of Boost20
The Microsoft STL is now open source (I'm sure you've all heard about it), So in the case of Microsoft, it suffices to create a PR and upstream the better boost library
Sadly not. It mustn't break ABI. Example: I proposed they implement the never-valueless variant for cases where this is possible the same as GCC/Clang do, but it was refused due to ABI. So good luck with boost::regex...
User perceptions about bloat may be related to the download size.
It is also about compile times and binary size. Using MP11 over MPL reduces the former, using std:: types over boost types (may) allow to generate less code as template instantiations of the types in use are also used in user code already. So using `std::optional<bool>` in user code and `boost::optional<bool>` in boost internals or interfaces means twice the code for the same functionality (unless references inside are used of course)
But I fear that (like other projects like Cmake) the BIG hurdle that we struggle to get over, is *resources*.
This is the main point of the proposal: It is a gradual way. Lets say it is "switch to C++11 - lite". No one is forced to do anything but developers are incentivized to drop dependencies where possible and there would be a way to measure progress. This can happen Boy-Scout-Rule: Where you fix stuff, clean/update the surroundings. Gradually you'll have a "clean"/updated library
Tests and tests data are another area that many users rarely use, but separately them would be a big task.
Sorry? Simply remove all test folders before uploading the tarball. Done. For the tests-release: Simply remove all folders BUT the test folder. The names are standard already so that is easy.
Boost.MPL and Boost.Mp11 are very different in API, which means that a library that uses template metaprogramming and wants to support C++03 and later cannot be compliant with the Epoch requirements, unless it contains two versions of the TMP code
That is one of the points of the epoch proposal: MPL has known shortcomings (mostly compiletime) that are "fixed" in a C++11 library (MP11). So the authors/maintainers are incentivized to drop the MPL dependency for MP11. if they don't because they care about C++03 (from your statement above) for some reason, they (rightfully) don't get a badge saying "Boost11". So what? No harm done except C++11 and up users know the lib uses some old/slow dependency and can decide to not use it if they don't deem this useful enough to offset the cost (see top)