All valid points and as you say it yourself, all addressable. The thing is though, Canonical can control this experiment by deciding on what debs get migrated t

All valid points and as you say it yourself, all addressable. The thing is though, Canonical can control this experiment by deciding on what debs get migrated to snaps. They can easily conduct this experiment in an LTS so long as they only keep it to desktop packages like GNOME components, browsers, third party software, etc. That way they don't have to wait yet more years before providing this system for use by all users and developers. For example I love the fact that VS Code and Spotify update on their own with no interaction required. I wouldn't love if something I don't want to update in our server fleet gets updated but I don't see many snaps in that area. But if we do see that I'm sure both of us can come up with a one liner stopping snap from updating if and until that use case is supported. Besides, the server space is gravitating towards immutability anyways, so doing something like `chmod -x $(which snapd)` or `chmod -x $(which apt)` on a production machine shouldn't be a big problem in that context. In fact that's one foolproof way to make sure packages are what you want them to be after installing them. Or read-only file systems.