On MacOS or Windows (maybe even Linux with the Mozilla updater, never tried it), the updater does the update on the next restart.
Chrome on macOS and Windows keeps itself up to date; for whatever reason Chrome on Linux installs a google.chrome repository, uses the distro package manager, and clobbers the running binary. shrug
This is not a problem on Unix-like systems, actually. Any running process, that has some file open, will keep the original file open, even if the filename points to another file now. Only processes that open the file after the change will get the new version.
I suspect that the protocol that multiple processes of Firefox used to communicate together could change between version and the mismatch between old and newly launched processes caused the problem. So it is versioned now, and if the versions are mismatched, warning is being shown.
> for whatever reason Chrome on Linux installs a google.chrome repository, uses the distro package manager, and clobbers the running binary
As others have said, it is actually the right approach. The custom updaters for Firefox and Chrome under Windows and MacOS are there, because they are lacking any system for centralized package management.
Flatpak solves this in a third way: it doesn't clobber the current tree, it creates a new, separate one and signals the application, that it was updated, and can restart into a new version, when it is convenient. It gets the best of the custom windows/mac updaters (not overwriting running apps), together with the best of linux package managers (centralized management).
Because that's the proper way to do things instead of each application bypassing the package manager and downloading updates and whatever else behind your back. How would you track and control updates if each application you use decided to do its own thing? Secondly, if installed to system directories, applications cannot write there without superuser privileges.