So I do have my own reasons, and BTW Boost.Locale is written with backward ABI compatibility in mind.
So once boost "stabilization" would be started as official part of boost I'll be the first who helps.
Don't get me wrong, though. I do find it valuable to explore solutions to solve ABI problems. I just would not like to see the boost community being split into those who work on what boost is now, and those who are always caught in a "should we fix this bug? it makes applications break, but fixing it would break the ABI" dilemma. I think a particular virtue of boost is that bugs are fixed, and that they are fixed in the exact place where the fix belongs, even if that involves breaking the ABI. Everything else would be a workaround to some extent. But I do find it useful to have some control over the ABI. Not because I want to deploy software in environments where people randomly throw together modules compiled against different boost versions, but because I need updating strategies for large deployments of binary modules which are a bit more granular than "upgrade boost, then recompile everything". However, today's possibilities are different from what was possible before. I think fixed binary ABIs are less important today than they were some years ago. Today, good compilers are affordable, computing power sufficient for compiling is affordable, sophisticated source code management systems are available, programming paradigms have evolved etc. This allows for more heterogenous environments. We do not need to strive for having all software converge to a fixed goal which doesn't evolve anymore (just waiting for the day it breaks), but we can have software evolve even more dynamically because there are tools to make sure that all components still find other components they are compatible to. Best regards, Isidor