Thanks for letting me know it can be done. I actually just finished making it all work with a single buffer, and everything seems to be working fine so far. I would like to make the number of buffers user selectable, and I will probably use some of the suggestions in this thread when I start working on that.

Copying a block looks something like

I needed to move one of my blocks and made use of the fact that BUFFER leaves the data in the one and only buffer in place, so I only needed:

That only works, of course, on a single buffer forth where the word BUFFER doesn't just have BLOCK in it, which I've seen in some other Forths. Your code is much more portable as it will work on any Forth that supports blocks.
Thanks for the demo of using PAD, in any event. I always forget that it's there and this is the perfect example of its use.

Well, ideally, copy would be a system specific primitive that knows how to reassign the block numbers that a buffer is allocated to. Then it just tweaks the assignment and marks the buffer as dirty.

But that requires PAD to be at least 1024 bytes.
If BUFFER never reads from mass storage, this version of COPY will work with one buffer or many:

It's better if it doesn't, at least on the Commodore 64. The C64 has a full 64K of RAM as well as kernel ROM, BASIC ROM, and memory mapped I/O. The memory configuration controlled by locations 0 and 1 ( and two lines on the expansion port.) If a programmer wishes to copy the kernel ROM to RAM, modify it in some way and switch in the new Commodore kernel then the following will work.

On the C64, when the ROM is switched in it is read during a memory read( of course), but any write to that address range will write to the underlying RAM.