Honestly, if boost was changed to use these indirection techniques in all places, I'd probably fork it or go for an alternative solution.
I do not suggest having all boost abi-stable but take most valuable stable and important parts (tr1 for example) and make them such or, add ::boost::stable or ::unboosted namespace and put there all stable parts.
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,
Of course not every part should be pimpl-ed and many can't.
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.
Agree
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.
This is good point. Linux kernel unstable for Driver development so you need to compile each driver with specific kernel (or just get it into kernel). But it is SUPER stable for user. System calls are never (or almost) never removed and keep their compatibility. So given right libraries you can run code compiled for Linux 2.0 on Linux 2.6.32 Artyom