If changes break the previous data format (a particular type of breaking change that may make it impossible to use older files with the snap - quite a serious issue!) then, when epochs are implemented, the application won’t be automatically upgraded to it, at least, that’s how I understand epochs work? @niemeyer can confirm. I don’t see why ‘breaking’ changes in terms of API or UI changes need to be held back (though they can be disruptive if someone is doing a mission critical task, they launch the app, and it takes them longer to navigate the UI/API, does the snappy team recognise this as a potential issue? Maybe the application author is allowed to specify a new epoch for this kind of breaking change too?)
This is risky because snap maintainers may not be using them correctly and people expect a consistent experience when using tracks… I think this is an element of control which snappy may be justifiably reluctant to give to developers, can you elaborate on why handing over control of these is justified? I mean, it should be possible perhaps for a track command in snapcraft to automatically create a new thread on the forum requesting a new track? You’re right that tracks help to resolve this problem, if a user specifically requests to avoid breaking changes, then assuming the tracks are used correctly and the project uses Semantic Versioning, tracking e.g. the 2.x track (probably just called ‘2’) will not automatically introduce breaking changes and you’d be able to manually choose when you want to switch to a more recent track.
Yes, the snappy team say that devs should be running automated tests etc to ensure that updates don’t cause these problems, but in case they do occur, those using snappy in mission-critical situations should be using the refresh timer to ensure that they can update at a time that they expect. Updates can be delayed for up to a month (I think?) by using that method. Sysadmins are effectively not permitted by snappy to delay their updates for longer, because snappy reckons that to do so is to endanger their users to possible security vulnerabilities etc (you can say that ‘well they should only get automatic security updates’ but often security/bugfix updates are not applied to old releases and a minor or major update is the only way to get the security update) and snappy believes that it has a role to protect its users, even against sysadmins’ wishes. I’d say that snappy forced updates are much better than Windows updates, from a user’s perspective, because, like most other GNU/Linux updates, they must more often don’t have to be applied when restarting the system, so you can actually use your computer whilst the updates are being installed!
Why would I, as a GNOME (albeit the Ubuntu modified session) user, need to spend time to learn a (somewhat) new desktop paradigm in order to use my desktop? Well, I do, because the devs chose to change the desktop paradigm and I’m fine with that! If I absolutely despise it, I can get on GNOME’s GitLab and IRC and fight for change (as you can do for snappy in this thread), if I want more leverage I could contribute to the project elsewhere and hope that, by meritocracy, I would get more of a say on this issue, or if I absolutely despise the paradigm change, I can use a different desktop environment, or package manager.
The snappy team reckons that a paradigm change is needed when it comes to updating software, can you prove to them that it is not? And since this (presumably, like Ubuntu) is a meritocracy, not a democracy, they’re not obliged to listen, though I think the team have done a sterling job of at least replying to criticism in a good-natured way, despite their workload 
Yes, if you absolutely despise snappy’s forced refreshes you should switch to Flatpak, AppImage, Nix, or traditional packaging 
That’s a neat quote, but is it true? Can you give an argument in support of this statement, or are you intending it to be a tautology (because it doesn’t seem to be, I’m not convinced those two things are mutually exclusive)? I guess it’s on the snappy team (primarily @niemeyer since this strategy is his idea), and supporters of the current approach of the team, to find an example where a technical solution has indeed solved a social problem. Perhaps undesirable work can be considered a social problem which automation could potentially resolve? So one can see how technology can in fact solve social problems, and your statement is not true? We only have to find one example to prove that your statement is false, and I think my example works!
Also, what will create change here, as ever, is actual use cases (like the LXD one - preferably with logs) that show why the current solution isn’t working, and the minimal possible changes to fix the use cases, short of introducing an off switch, if possible. If an off switch is the minimal solution, then it needs to be demonstrated why that is the minimal solution, why other apparent minimal solutions don’t work.