those who are always caught in a "should we fix this bug? it makes applications break, but fixing it would break the ABI" dilemma.
ABI compatibility should not prevent fixing bugs. This is important point. In fact libstdc++ manages its ABI for 6 years successfully, Qt does this very well too.
These are very different cases. libstdc++ implements functionality which has been standardized for a long time. Qt uses a lot more indirection than boost does.
However you need to be prepared. You generally need at least one d-pointer/opaque-pointer/pimpl. You need to separate implementation and definitions (it would also increase compilation time, and reduce code size).
Honestly, if boost was changed to use these indirection techniques in all places, I'd probably fork it or go for an alternative solution. Indirection might solve the fragile interface problem and reduce compilation times and code size, but it also effectively blocks any compiler optimization which spans multiple methods that could be inlined before. Consider boost::phoenix: as we have it now, without indirection, I can write expressions using phoenix and count on a decent compiler to optimize all the classes out, leaving me with native code which often is no different than if I had coded the expressions by hand. A pimpled boost::phoenix would result in lots of indirect calls all the time, which would badly hurt performance. As stated before, I would consider it useful to have a boost::abi module which abstracts away the internals. This would probably use one of the indirection techniques you mentioned. But I don't think something like this should be scattered throughout the whole boost. I would not want to have yet another lightweight layer which could fit between boost and C++. I'd rather think of boost as a toolset sitting right on the top of C++, which is not necessarily binary stable, but can be used to build the hard bits of a binary stable library. BTW, I would rather compare boost not with Qt or libstdc++, but with Linux kernel development. They also work at a very low level, and they came to the conclusion that a fixed ABI would be to costly. I think a fixed ABI is something that should only be considered on a higher level.
I need updating strategies for large deployments of binary modules which are a bit more granular than "upgrade boost, then recompile everything".
Exactly, this one of very important issues that ABI stability would solve.
It surely would. But I do not regard it as the best solution. A stable ABI would just mean even larger deployments using the same ABI, just waiting for the day where some design issue makes it unavoidable to break the ABI. Then the problem is even bigger. A better solution, at least in the boost case, would be to make a volatile ABI more manageable. Best regards, Isidor