Getting back to the issue at hand (creating a "base" library), I would like to give my humble perspective on it. I think that the root of the problem is that a lot of the fundamental libraries in Boost, like type-traits, mpl, pp, utility, etc..., all have in common the fact that they have a few extremely useful components that are used widely both in the user-base at large and by other boost libraries (or could be used by them), and often those components were the original motivators for the creation of the library, but they also all have a number of additional "fancy" features that make sense within their prime application domains (and you can't blame library devs for wanting to fancy-up their libraries) but also constitute significant additional bloat for all those people who only need the few useful components. For instance, most people probably use the MPL for its basic meta-functions, especially the boolean stuff (if_, not_, and_...) for Sfinae and type selectors, but very few people need or want to use the whole "compile-time STL" part of MPL. The type-traits library is the same. And I think that if it were possible to distil things down to some basic components, much of the cross-dependencies and code-bloat would be eliminated, and other boost libraries could rely on those components without too much concern about getting bloated by them. I seems to me that the Boost.Core library is intended to regroup those things. But the real problem with getting a good set of components to put in Boost.Core is that there is no clear picture of what people want and what people don't want. The dependency analyser cannot capture things that people (from other boost libraries) would want to use but decided not to use (by implementing their own reduced version of it) for fear of too much bloat and dependencies, and nor is it really fine-grained enough for this purpose anyways. I think there might be a need for some form of voting/review system for people to be able to declare what specific components they would like to see added to Boost.Core (that would help them avoid the dilemma of dep./bloat versus code duplication) versus what specific components / features would need to be factored out of the code (or left out of boost.core) because of it being overly bloated. This would clearly have to be more fine-grained than just on a header-by-header basis. And the boost mailing list is far from providing an adequate forum for this type of thing. Or maybe people simply need to be more proactive in raising issues on Boost.Core's github, as I know people seem to still be just warming up to that mode of discussion. Of course, from a practical standpoint, this is difficult to realize, but I just felt I should throw that idea out there. P.S.: I find that this discussion also exemplifies what I see as a big problem with Boost discussions, that is, any decision-making discussion on broader issues quickly digresses into people raising their favourite pet-peeves (like compiler support reqs, git submoduling, distribution issues, etc.) and discussing small examples at length (like integral-constant). Cheers, Mikael.