## Summary

`omarchy-hyprland-monitor-scaling` — used by the Display panel's SCALE buttons and by `SUPER + SLASH` / `SUPER + ALT + SLASH` — misbehaves in three separate ways on a multi-monitor setup where `monitors.lua` pins per-output scales and positions. Together they make the scale buttons appear to do nothing while silently damaging the user's config.

The command assumes `monitors.lua` still holds Omarchy's generic catch-all defaults. When it holds explicit per-output `hl.monitor()` lines instead — which is what the shipped comments in `monitors.lua` invite you to write — every part of it goes wrong.

## Environment

- Omarchy 4.0.0-1
- Hyprland 0.56.2
- AMD Ryzen 9 9950X3D, NVIDIA RTX 5080
- Two monitors, per-output scales and pinned positions:

```lua
hl.monitor({ output = "DP-3", mode = "3840x2160@240", position = "0x0", scale = 1.333334 })
hl.monitor({ output = "DP-2", mode = "2560x1440@144", position = "-2560x200", scale = 1 })
```

## Defect 1 — `sed -i` destroys a symlinked `monitors.lua`

`set_scale()` persists with:

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

GNU `sed -i` without `--follow-symlinks` writes a new file and renames it over the target, replacing the symlink with a regular file.

Anyone managing dotfiles with GNU Stow (or any symlink-based manager) has `~/.config/hypr/monitors.lua` as a symlink into their repo. The first scale-button click breaks that link permanently and silently. The repo stops driving the config, and nothing surfaces the change — in my case it went unnoticed for four days, and was only found while investigating Defect 2.

**Repro**

```bash
mv ~/.config/hypr/monitors.lua ~/dotfiles/monitors.lua
ln -s ~/dotfiles/monitors.lua ~/.config/hypr/monitors.lua
ls -l ~/.config/hypr/monitors.lua          # symlink
# click any SCALE button in the Display panel
ls -l ~/.config/hypr/monitors.lua          # now a regular file
```

**Fix:** `sed -i --follow-symlinks`, or resolve with `readlink -f` before writing.

This one is worth fixing regardless of the rest — it is silent data loss for a common setup.

## Defect 2 — persistence writes one global scale, so the change reverts instantly

`set_scale()` only ever rewrites `local omarchy_monitor_scale` (or the `output = ""` catch-all line). Both feed the generic catch-all rule. An explicit per-output `hl.monitor()` line later in the file overrides it, so:

1. `hyprctl eval` applies the new scale — this part works;
2. `sed -i` writes the global variable, which is not what governs this output;
3. the write trips Hyprland's autoreload, which re-applies the per-output line and reverts the scale within milliseconds.

Net effect: the buttons look completely inert. Nothing in the UI indicates a change was attempted, applied, and undone.

`~/.local/state/omarchy/monitor-scaling.log` shows the fingerprint clearly — every entry records the same `current=`, even for clicks seconds apart:

```
at=...T12:20:07 requested=1.25 current=1.3333334 new=1.25 monitor=DP-3
at=...T12:20:19 requested=4    current=1.3333334 new=4    monitor=DP-3
```

**Repro**

1. Put an explicit `hl.monitor({ output = "<name>", ..., scale = 1.333334 })` line in `monitors.lua`.
2. Focus that monitor, click any SCALE button.
3. `hyprctl monitors` still reports the old scale.

Confirmed the two halves independently: an `hyprctl eval` of the same `hl.monitor()` call holds indefinitely on its own, and appending a single comment line to `monitors.lua` is enough to snap the scale back.

## Defect 3 — `position = "auto"` rearranges the desktop

The runtime half hardcodes `position = "auto"`:

```bash
hyprctl eval "hl.monitor({ output = \"$active_monitor\", mode = \"...\", position = \"auto\", scale = $new_scale })"
```

This discards the position from `monitors.lua`. Clicking a scale button moved my secondary display from `-2560x200` (left of the primary, 200px lower) to `2400x0` — the opposite side of the desk, offset lost. `2400` is the primary's logical width at the newly chosen scale, so `auto` simply re-packed the outputs left-to-right.

**Repro**

1. Pin two monitors at explicit non-default positions.
2. Click any SCALE button.
3. `hyprctl monitors` shows the outputs re-packed from the origin.

**Fix:** pass the monitor's current `x`/`y` rather than `auto`.

## Suggested direction

Rewriting the `scale =` value on the focused output's own `hl.monitor()` line, then letting the autoreload apply the file, fixes all three at once — mode, position, scale and workspace rules are re-applied together, the layout cannot drift, and the change persists across reboots. On that path the `hyprctl eval` becomes unnecessary; it is only needed as a fallback for a monitor that has no line of its own, and even then it should pass the real position.

Falling back to the existing global-variable behaviour when no per-output line matches would keep current setups working unchanged.

I am happy to open a PR if this direction sounds right.