I could never remember the operand order for `ln -s x y`, and now I've realized why: the command supports two simultaneous parsings.

`(ln -s) (x y)` — the intended reading. `-s` for "symbolic," argument order same as in `cp x y`. Fine, but I don't trust such analogies — not after `find`, `dd`, or `tar`.

Also, it is weird how at birth we denote the symlink as `x y`, but later if we `ls -l y` we'll see `y -> x`. Why the reversal? Using `ln -s` makes `-s` powerless to impose a convention: only the link itself is qualified as symbolic, and it is left to us to figure out what that means for the operands.

`ln (-s x) y` — my reading. `-s` for "source." You're declaring x as the source of content for the new name y.

"But wait, x is called the 'target' in symlink terminology!" This was my confusion. I'd been treating "source" and "target" as antonyms, so the mnemonic kept breaking. But x is both: target of the link, source of the content.¹

All symlinks to a resource form a tree rooted at the original:

v1/ ← original

  ├── v2     (ln -s v1 v2)

  │   └── v3 (ln -s v2 v3)

  └── v4     (ln -s v1 v4)

Each `ln` with `-s` extends a branch. The partial order `x < y` (iff `ln -s x y`) is even witnessed by `st_birthtime` — the filesystem records the Hasse diagram's construction history.

tl;dr: `ln -s old new` pushes `new` onto a stack rooted at `old`. The `-s` is for "source," not just "symbolic."

---

¹ Like how topology students eventually realize a set can be both closed and open — the words aren't antonyms, just independent properties. I wonder what formal topology scaffolding could make "source" and "target" correspond to "open" and "closed."