What’s most frustrating is that snap knows the entire state of the world! They know when the application is started and closed. Could download the update at anytime and upon closing the old application, link to the update and delete the old version.
Snap format is just a single compressed file. They could literally just replace it, remove the old one and due the way of which Linux filesystems work, any new call to app will run the new one, but the old one would use the old file.
They could do it basically seamlessly, with maybe notification only if you keep app running for days. Hell, that's how package manager does updates, just remove old libraries and put a new one in place, old programs will use the old one till restart, and when last filedescriptor closes it will be unlinked from filesystem. It sometimes can cause problems in "normal" apps but fact snap is just a single file removes pretty much all drawbacks of that.
It's not just bad decisions but incompetence on top of that
Snaps don't actually work that way. Snaps are squashfs images, which imposes the contract of requiring to unmount the old image before mounting the new one. When files are in use, you can't easily unmount. (Yes, you can use a lazy unmount, but bad things happen on the system with those, so it's not a good idea to rely on it!)
I think you're thinking of Flatpaks, which are basically hardlink/reflink farms with symlinks used to control the pointers to the current version (OSTree).
Which is basically how web workers work. Download silently then either use the new one on restart, or add some app level code to ask the user if they want to take the update now. At which point its a minimal install process since most of the work has been done already.
