You’re clearly a bit frustrated about the topic, and as a consequence word the problem in a confrontational way which creates an us vs. them situation that detracts from the real point. As mentioned above, the issue that makes us resist the idea of simply disabling updates altogether is that very often it will mean never to update rather than update at someone’s discretion, and then we’re getting back to some of the problems that got us here in the first place. That’s why we’ve been resisting introducing that global switch, at least for the time being, and instead working with people to mitigate the undesired side effects of having automatic updates enabled.
On that route, a number of features have been created and others are on the pipeline, such as the transactional operation foundation, multi-revision installations which keeps N revisions around for safety, pretty much instantaneous reverts across these, tracks which enable software publishers to only force updates on critical issues, epochs which introduce stepped upgrades, carefully scheduled updates, health checks which allow ensuring that a revision is safe to update to before it is completed, and so on.
That’s the attitude being taken by this project, and that is not towards you or anyone else. This attitude is towards the problem of enabling systems to be up-to-date and safe. We may very well introduce a trivial global switch at some point, but right now the priority is in working with the community on the low sides of automatic updates, and the examples above are very concrete results of that.
Sounds like this is a problem you’re also very interested on, so your contributions and opinions around improvements would be appreciated. We’ll also understand if your personal priorities and preferences take you elsewhere, though.