In my case, I’d use a ZFS snapshot. Many equivalent tools exist on different OSes and filesystems as well.

Really? Should I be snapshotting the volume before every "rm"? Even if it's a part of routine file exchanges between machines? (As it happens for many production lines, especially older ones).

I think the current semantic of "rm" works fine. But I understand the new world where we'll perhaps gonna be deleting single files using Terraform or cluster of machines, or possibly LLMs/AI agents.

Oh, I don't think we should change the semantics of "rm"--not because reversibility is unimportant (shameless self-promotion: it is: https://blog.zacbentley.com/post/on-reversibility/), but because baking it into "rm" is the wrong layer.

Folks usually want reversibility in the context of a logical set of operations, like a Terraform apply. For shell commands like "rm", the logical set of operations might be a session (having a ZFS snapshot taken on terminal session start, with a sane auto-delete/age-out rotation, would be super useful! I might script that up in my shell profile in fact) or a script, or a task/prompt/re-prompt of an AI agent. But yeah, it definitely shouldn't happen at the level of a singular "rm" call.

Since filesystem snapshots (in most snapshot-capable filesystems, not just ZFS) are very simple to create, and are constant-time or otherwise extremely fast to perform, the overhead of taking this approach wouldn't be too hard.