If I may put my two cents… I’m reading about last problems and being Juce user for almost 10 years I noticed that such huge complications happen most often in plugins related stuff. Issues with base classes (usage independent) even if the classes are completely new or modified a lot are mostly minor and fixed very quickly and then such code stays stable forever.
When you reorganize plugins stuff there are always some troubles - no matter how much you modify the code. And to be honest it has to be like that (IMO) - plugins code is used in such different situations that I don’t believe that ‘stable’ state even exists. Even if you don’t make any changes then host apps/formats/OSes can change and cause the issues which need to be addressed.
It’s not about how to avoid the problems but how to live with them keeping peace of mind 
Here I also vote my two hands for separating the branches for different purposes because it’s mostly about the JUCE repository management - the old hidden problems mix with the new unexpected problems from the outside world and mix with the fresh problems coming from new features not tested enough - and that’s the PITA. Using something similar to GitFlow management would fit perfectly here.
Having develop branch (and feature branches if you want) you could commit what you want - new turbo-ultra-inspiring features showing us where you want to go and giving us a chance to test it and giving you our feedback. All the revolutions go here and every bug is welcome.
One release branch if you decided that it’s good time for new Juce release. You close some state to test it more before it becomes new version. Only bugfixes are made to release branch and for example after 4 weeks you could simply release new version knowing that it’s as stable as possible.
Then we could always rely on master branch and use it for our important releases. And if anything from the outside world (hosts/OSes/compilers etc) cause the problems you could simply make a bugfix to the master branch (merging it also to develop branch or wherever you want).
I don’t agree that you at Roli should make all_the_tests for plugins stuff: all the major DAWs, OSes etc before committing anything. It’s waste of your time. Please focus on Juce development and make the basic tests only. If we had dedicated branches you could make deeper tests only on new releases and we could help you then testing it also on our sides. It would be great time saver for you and us.
Cheers