PLC-5 is forward also. Here's why:
When the PLC executes the COP instruction, it copies the value of .POS in the control word the S:24 word -- the one used for indexed addressing.
Then, when executing the COP instruction, it then uses indexed addressing as a one-element-at-a-time copy. That's why the files are prefixed with the '#'. If the instruction were, say, COP F8:0 #F9:0 7, you would be creating a File Fill command, populating everything in F9 with the single value in F8:0.
Thus, for COP #F8:0 #F8:1, the value of F8:0 goes into F8:1, the value of F8:1 (which just came from F8:0) goes into F8:2, etc. Which then also winds up acting just like a FLL (Fill) instead of a FFL (FIFO).
The PLC doesn't allocate memory (unlike a PC) to copy all of F8:0-:6 into a buffer, and then copy from that buffer into the destination, as Peter is suggesting it "should". Those early PLCs had no memory to spare. And if the COP did as Peter suggests, then the instruction COP(ArrayA[0], ArrayB[0]) would copy the values in reverse order ?!? That would be "wrong" too.
As we all know, the PLC can't understand the intent of the programmer; it will only do exactly what it's told to do, for better or worse.
That's why those of us who use the COP instruction as a quickie FIFO would usually load from the top (F8:7) and copy backwards (COP #F8:1 #F8:0 7).
But it is more esthetically pleasing to have the first (zeroth) register being the most recent data, so we'd do what you did, and copy it an intermediate register then copy it back to the source.