the removal that had to be undone

One component was removed from a machine's definition outright, along with the packages that came with it. The change was small, made sense at the time, and survived about a day. Two commits later the same component was back, with two specific things changed, and the second version is the one that stayed.

The removal was not stupid. The component had been misbehaving under behaviour it enabled by default, and deleting it is the fastest way to stop a misbehaving thing. What the removal missed is that it answered a symptom: the fault sat in how the thing was activated and how it mapped identities onto users, not in the thing existing at all. Deleting it made the symptom disappear and took a capability with it.

The restoration is the interesting commit. It brought the component back, made a default-on subsystem explicit in the activation, and fixed the identity mapping that had been quietly mangling the ownership of files. It also surfaced a residue: removing the component had not removed the group its installation had created, and that membership was kept on purpose, so the identity the account carried outlived the thing that motivated it.

The cost is two rewrites of one declaration and a standing explanation of why the obvious move was wrong — more documentation than either change deserved on its own.

What it proves is that undoing a deletion requires knowing why the thing existed, and that knowledge is cheapest to write down while you are removing it.