It doesn't seem like such a fundamental difference to me.

Then you either haven't taken the time to think before commiting to that opinion, or you simply haven't bothered to consider the possibility that a unix behaviour could possibly be flawed.

Modifying the wrong hash element in an inhereted object can cause data loss.

Modifying the wrong hash element is entirely within the control of my application.

Overwriting or deleting a file created by a different application (or vice versa) is not.

Changing a global sub (such as you do here) can cause serious problems if not done with care.

I didn't "do it". I simply reminded someone else how Perl would let them do it, should they choose to.

And besides, all the behaviors of an operating system are controlled entirely within the auspices of one computer.

And if the files resides on a network drive or NFS mounted filesystem?

The difference I see is not fundamental, it is one of likelihood. The chances of problems caused by permissive behavior are less at the application level than the operating system level, but they are still there.

What makes the difference fundemental is that I can code my application to test for and avoid modifying the wrong hash element.

To safely rename a file requires that the OS detect and inform me about potential collisions, as any test I code into my application opens a race condition on a multi-tasking system.

My OS does this at the system API level. The thing that took me by surprise was that the Perl implementation chose to override this.