[ianswope]

Docking a laptop to two external monitors makes every allowlisted message
fire three desktop toasts — one per screen. It stays that way until the
shell is restarted; undocking clears it.

The leader election (war room #0) is doing its job. Two things defeat it.

1. Everyone is the leader for the first few hundred milliseconds

QsWindow.window is still null when a freshly built bar completes its
widgets, so on a hotplug every screen's widget satisfies !ownScreen at
Component.onCompleted and crowns itself. A sandboxed Quickshell running
the current expression verbatim, on a three-monitor setup:

PROBE init panel=eDP-1 qswindow=NULL ownScreen=NULL screens0=eDP-1 nscreens=3 LEADER=true
PROBE init panel=DP-1  qswindow=NULL ownScreen=NULL screens0=eDP-1 nscreens=3 LEADER=true
PROBE init panel=DP-2  qswindow=NULL ownScreen=NULL screens0=eDP-1 nscreens=3 LEADER=true
PROBE late panel=eDP-1 qswindow=ok   ownScreen=eDP-1 screens0=eDP-1 nscreens=3 LEADER=true
PROBE late panel=DP-1  qswindow=ok   ownScreen=DP-1  screens0=eDP-1 nscreens=3 LEADER=false
PROBE late panel=DP-2  qswindow=ok   ownScreen=DP-2  screens0=eDP-1 nscreens=3 LEADER=false

By the time it settles, running: root.leader has already started an
imsg watch on all three.

2. The demotion kills the follower's watcher, and its own backoff brings it back ungated

Settling flips leader false, the binding sets running = false, the ssh
session exits. onExited reads that as a failure — watchFails goes to 1,
watchRestart arms — and one backoff later:

onTriggered: watchProc.running = true

A bare assignment replaces the running: root.leader binding permanently.
From that moment the follower watches, refreshes and toasts forever, with no
gate left to stop it.

Evidence on real hardware

Three monitors, one shell process, after docking:

172332  ssh ... mini imsg 'watch'   started 13:59:41 - 16s   (bar rebuilt 13:59:25)
2907705 ssh ... mini imsg 'watch'   started 13:59:41
2907706 ssh ... mini imsg 'watch'   started 13:59:41

16 s is exactly 8000 * Math.pow(2, 1) — watchRestart's first backoff. The
shell log shows two rejected nixfred.blip IpcHandler registrations at
13:59:25; that handler is enabled: root.leader, so all three widgets
genuinely believed they led:

13:59:25.494 WARN scene: QML IpcHandler at .../BarWidget.qml[838:3]:
  Handler was registered but will not be used because another handler is
  registered for target nixfred.blip
13:59:25.741 WARN scene: ... (same, third widget)

The 6 s poll Timer { running: root.leader } has no imperative write and
stayed correctly single — which is what pointed at the binding clobber.

The fix

• watchRestart restores the binding (Qt.binding(...)) instead of assigning
  a bare true.
• An unresolved widget waits instead of racing when more than one screen
  exists. One screen or none still defaults to leader — that is what keeps a
  widget outside any window working, so the single-monitor path is unchanged.

watchLiveness's running = false also drops the binding, but the restart
path re-establishes it immediately, so it self-heals. Left alone.

Verification

• 486/486 bun test pass.
• Each new test fails when its own fix is reverted, and only that one
  — checked both ways, individually.
• Root cause reproduced in a sandboxed Quickshell instance (output above),
  not inferred from reading.
• Timing of the duplicate watchers matches the backoff arithmetic to the
  second.
• Not verified: the post-fix behaviour on a live re-dock. The fix is
  installed here and the shell has been restarted, but the machine is
  currently undocked, so the three-monitor path has not been re-exercised
  end to end. Worth a second pair of eyes on a multi-monitor setup.

[nixfred]

Merged, thanks @ianswope! duplicate toasts on extra monitors are gone. Tracing it to the watcher restart overwriting the leader-only rule, and matching the 16 s backoff to the process start times, was excellent diagnosis. It's in main as of 186b536 and deployed on my machine. I merged it together with nine other PRs, and all 526 tests pass on the combined tree.