[...] I think there are definite advantages to unifying this behaviour by providing a mechanism for copy-on-write on a per-slot basis. For example, in a word-processor I might want all paragraphs to appear in a default typeface unless specifically overridden by the user; if the default is changed all paragraphs which have not been so overridden should reflect that change; and a paragraph-object with an overridden "typeface" ("style", whatever) slot should be revertable to the default behaviour by deleting the slot. I think that is what Alexis was getting at.
Interestingly enough, NewtonScript (the programming language used on the Apple Newton) has "copy on write" (COW) slots. One reason for including COW (as I understand it, I'm not a Newton programmer) was to save space: clones only need to hold changed slots, not all slots. In the Newton, the prototype's slots can even be in ROM (no prototype corruption problem here :-), further saving precious RAM.
The problem with COW is that there's no straightforward efficient implementation. For example, if an assignment grows an object, the implementation has to make up a new object and redirect all pointers to the old object. That's only fast if you use indirect pointers (i.e., an object table), which is acceptable for an interpreter but slows down a compiled system quite a bit.
However, there may be some clever trick to implement COW efficiently. Sounds like a Ph.D. thesis to me... :-)