Hey Stephen, This is a extremely well written and reasoned post and I can't help but I agree with every point you made.

As for breaking existing use cases, this will cause us to stay at the last release that meets our needs until the beginning of a new major release cycle on our side, unless there's some other feature that compels us to deal with the breaking change mid-cycle.

In my previous position, I worked in the firm's infrastructure group, where we wrote and maintained libraries that were the "standard library" of the firm on which other apps/libraries were built. Given the size of the user base (in the thousands), it is simply unthinkable to rebuild the world because of a new release of boost. The current version is 1.33.1 and that's unlikely to change for a while. Finding debilitating bugs/changes in a new release makes people even less likely to want to move. This is bad for boost, too, as you lose not only direct boost users/testers, but also the feedback that developers send back to their compiler/standard library vendors.

Open-source status gives you champions in the development pit but it doesn't change management's priorities.

Nor should it make one forget that even though grateful for your efforts, there's only as much pain as people are willing to go through. Tom