otherwise just one page is copied (and afterwards, the copy is modified). As such, this example of events is misleading.

The problem with this view is it kind of implies that (say), iterating a small array will only entail copying one 4k block. The reality is that the AV is likely to be allocated in a different block to the xpvav; which is quite likely to be in a different block to the SV with # magic; which is in a different page to the SV*array containing the alloc; which is in a different place to the block containing all the SVs holding the scalars; which may each be in a different block to the xvpv, xviv or xvnv they point to; which in turn are quite likely to be in different pages to actual pv data if it has any; etc.

And that was just an array. Take a close look at a hash; or better still a stash, and see all the separate allocations that go to making up the thing. And remember, perl's allocator tend to allocate like sized things from the same pools, so the individual elements of any single entity tend to be strewn around over several pages; not all together in one neat lump (page).

So whilst it isn't (nor was I implying), a 1 for 1, 4k block copied for every internal change. Nor do changes to a single entity necessarily only involve the copying of a single block. push, shift, pop or unshift an element to a small array, and several blocks might need to be copied as a result.

The CPU/MMU operations required to throw a page fault and allocate memory are insignificant compared to the time it takes to actually copy the data in memory.

I'm sorry, but I disagree. A page fault is a hugely expensive operation, because of the ring3-ring0-ring3 transition. Copying (within the auspices of a single process) a 4k block or even a 64k block is less expensive.

For an example of just how expensive page faults can be, see What could cause excessive page faults?.