So it sounds like you recognize the impracticality of a "solution" that involves overriding core functions and modules -- even though the "dream module" that you describe in the OP probably couldn't be implemented any other way (as near as I can tell).

Yet at the same time, it sounds like you are hoping to avoid the alternative of altering every line of existing code (or including a bunch of repetitive stuff with every line of new code) involving any sort of file-system change, so that it can be made conditional on the value of the "preview" option.

Alas, I don't think there's a third way. The best you can do is find ways to minimize the overhead of making all those file-system operations conditional. Ideally, this is something you plan out for before actually writing any code for the given application.

In that regard, my personal preference would probably fall toward a module that builds a stack of operations, then, you just check your option setting once at the end of the process, to decide whether to print the stack, or execute it, or present it for approval, or store it as a script file, or ...

If you're adapting existing code to provide this new functionality, it means editing every line that does a file system call, to turn that into a call to the module's "push" method -- no way around that. If you're starting a new app, it's not that much overhead to write $stack->push( "rename", $arg1, $arg2 ); instead of rename $arg1, $arg2; -- maybe there are ways to make the method call even easier.