I know why you want it. Ruby uses this (among other things) to support $` etc lazily without bugs. If you don't use the feature, you don't pay for it, and if you use it, you only pay for as much of it as you use. (By contrast Perl's hack with a global flag means that if you use it, you pay like heck.)

However if you try to use copy on write with magic in Perl, you will get serious bugs from the fact that magic and local have a well-developed distaste for each other. This would give efficient $` etc. But only at the cost of introducing weird bugs involving mixing matches and local variables.

Beyond that, any language with copy on write is best of (IMHO) using it aggressively and thinking through carefully the desired semantics. The reason to use it aggressively is that marking things copy on write is an excellent way to save lots of work on potentially expensive operations like assigning data to variables, and also it exercises your copy on write logic to catch any bugs. Both are good. (It is too easy to accidentally ignore copy on write somewhere and you want to catch that. Just like how the local and magic mechanisms in Perl ignore each other...) The reason to think about the semantics is that for things like argument passing there can be subtle differences between pass by value, pass by reference, and passing by aliasing with copy on write. Semantically the first and third resemble each other, but with profound performance implications. The second, in the right environment, can superficially look a lot like the previous two but with gotchas to be aware of.

For instance in comparing Ruby and Perl, a key point that is often missed is that in Ruby assignment is by reference, not value. Given that most operations in Ruby create new copies, this works out fairly naturally. But beware!

a = "Hello";
b = a;
b << ", World";  # Note: += would not do this!
puts a;
[download]

Anyways Perl has a well-established semantic model. If it was to add copy on write, it should think carefully on how to update that model...