### Environment

- Omarchy 4.0.2-1 (packages, on CachyOS), Hyprland 0.56.2, quickshell 0.3.1
- Lenovo Legion Go 2 (83N0), two outputs:
  - eDP-1 — 1920x1200@144, 8.8", 257 DPI (wants a fractional scale)
  - DP-1 — 1920x1080@60, 27", 81 DPI (wants scale 1)

### What happens

Setting a different scale per output requires explicit lines in
`~/.config/hypr/monitors.lua`:

```lua
hl.monitor({ output = "DP-1",  mode = "preferred", position = "0x0",    scale = 1 })
hl.monitor({ output = "eDP-1", mode = "preferred", position = "1920x0", scale = 1.25 })
```

That works — but from then on the **Display panel's scale presets in the bar do nothing**.
No error, no visual feedback: the buttons are simply inert. Restoring the stock
`monitors.lua` (the single `output = ""` catch-all) makes the panel work again. Verified in
both directions on this machine.

### Why

`omarchy-hyprland-monitor-scaling` has no per-output persistence. It applies the change
live and then persists it by rewriting a **single global** variable:

```bash
sed -i -E -e "s|^local omarchy_monitor_scale = .*|local omarchy_monitor_scale = ${new_scale}|" ...
```

That `sed` writes `monitors.lua`, which Hyprland auto-reloads — and on reload the file's
explicit per-output lines take precedence over the catch-all the variable feeds. So the
script's own persistence step immediately undoes its own live change.

Two consequences worth separating:

1. **The panel silently no-ops.** The script's persistence branch is gated on
   `grep -q '^local omarchy_monitor_scale = '`, which still matches a customised file, so
   it reports nothing wrong while having no effect.
2. **The live apply also discards positions.** It evaluates
   `hl.monitor({ output = "<focused>", mode = "...", position = "auto", scale = N })`, so a
   deliberate left/right arrangement is replaced by `auto` until the next reload.

Partial workaround, for the record: pointing only the internal output at the variable

```lua
hl.monitor({ output = "eDP-1", ..., scale = omarchy_monitor_scale })
```

does let the panel keep driving that one output, but the behaviour is confusing — using the
panel while the *other* monitor is focused writes the same variable and moves the internal
panel's scale instead. It is not a solution, just evidence of where the single-value
assumption sits.

### Steps to reproduce

1. Attach a second monitor.
2. Add an explicit `hl.monitor({ output = "<name>", ..., scale = N })` line for either output
   to `~/.config/hypr/monitors.lua`.
3. Open the Display panel in the bar and press any scale preset.
4. Nothing changes. Remove the explicit line and it works again.

### Expected

Either the panel persists per-output scale (e.g. writing/updating an
`hl.monitor({ output = "<name>", ... })` line for the focused monitor), or it tells the user
it cannot manage a customised `monitors.lua` instead of appearing functional.

Mixed-DPI setups make this concrete: an 8.8" 257 DPI panel and a 27" 81 DPI monitor cannot
share one scale value, so today the choice is per-monitor scaling *or* the bar control,
never both.

---

*Investigated and written with Claude Code (Claude Opus 5). Every command output, file
excerpt and measurement quoted above was taken from the affected machine.*