In other environments, programmers work on huge projects which might go on for years. In this constext, this is not such a huge problem as things are constantly evolving anyway.
If you don't mind me chiming in, it is a huge problem. With small projects, it's not difficult to keep the whole codebase in one's head if there are changes, to remember to go and fix the relevant places. The problem with most big codebases is precisely what you describe: They have evolved over a significant amount of time. No one developer may know the whole codebase. As a consequence, when changes are made, people are unsure as to the assumptions that were made by the original authors and all the locations where changes should go. Even with test cases, it's a little more like "plug and pray" than what you portrait here.
So continuing to break things and having to fix them is a normal and in any event unavoidable.
Certainly unavoidable but I would prefer for it not to be considered "normal" by the boost developers.
I try to avoid making a big commitment to a library - or anyone else's code so that I can drop one library if I have to in the future.
These things are much more problematic in large code bases. Once a library is in, it's likely to be there in ten years time.