Snap refresh behaviour is really strange.

Flatpak does work like this, and it's one of the motivations for it using libostree (which sets up hardlink-based immutable directory trees). Once an instance of a Flatpak app is running, its view of the app and runtime files in /app and /usr will never change even if the app or its runtime gets updated, ensuring that the app doesn't get broken by its resource files being swapped out underneath it (unlike system package managers like dpkg or rpm, which would traditionally just go ahead with changing the files in-place and hope the app can cope, but now often encourage doing "offline updates" during a reboot).

If you update a Flatpak app or runtime while the app is *not* running, then the old version will be cleaned up immediately (in the case of a runtime, this only happens if there is no running app that uses that runtime). If an instance of the app is running, it holds a lock which prevents that cleanup, but the "active" version swaps to the new one, so running another instance of the same app in parallel will give the new instance its updated /app and /usr. The old version will eventually be cleaned up, during the next update that takes place after the first instance has exited.

I don't know whether Snap does this. I would hope so, it's certainly in a position to use similar tricks if it wants to?

Of course, for particularly security-sensitive apps like Firefox, there's an incentive for the app to prompt you to exit and restart even if it's somewhat disruptive to do so, to make sure you're really running the updated version with its security fixes: there's a usability/security tradeoff here, and we can't realistically insert code changes into a running process, however important they might be.