I've mentioned this concern with DRAY on a previous topic (https://powdertoy.co.uk/Discussions/Thread/View.html?Thread=19703). With regards to that, the addition of "enmity" between CRAY and the first pixels it affects via .tmp2 has already been implemented.

Basically, while DRAY allows you to set the number of pixels to copy and a destination offset, it would be good to implement a property for DRAY that does the same thing as CRAY's .tmp2. Presently, I suggest using the .life property as it is apparently not in use.

DRAY's .life property: From what I've observed, setting DRAY to a nonzero .life will have the value decrement towards 0 every frame. For as long as DRAY's .life value is greater than zero, it will in fact not function and react to adjacent SPRK conductors. Seeing as no elements or reactions outside of console commands or the PROP tool could change DRAY's .life property, I would regard this inhibition as a bug. A function is also not assigned for .life in the original suggestion topic from https://powdertoy.co.uk/Discussions/Thread/View.html?Thread=18688&PageNum=1; erroneously, "active elements" like DRAY and CRAY in fact do not "conduct" with .life as demonstrated in 60 Hz saves. 

The change: Thus, provided that the auto-decrement of .life for DRAY and the activation inhibition .life causes to DRAY are removed, if .life was set to 5 where .tmp = 1 and .tmp2 = 1, once activated, the DRAY element will copy the first particle in front of it after 5 pixels of space and then apply its .tmp and .tmp2 to finish the copy. This effect is demonstrated in the save below under the "*Demo*" sign. See "Summary."

Application: In the save above, two setups are shown depicting the latest in TPT 60 Hz FILT memory. The former to the left features what is called a "double volume" memory with one "storage volume" and one "access volume." As demonstrated in LBPHacker's id:2012356 save, it is possible to dynamically switch DRAY attached to a PSTN writer with DRAY of alternative .tmp2s etc. This means that currently, we have the technology to implement a "single volume" FILT memory where data is directly written by a moving pixel of DRAY, depicted to the right of my demonstration save. That is, the size of FILT memory can easily be halved and in ways "simplified."

While the writing function has been addressed, reading poses a bottleneck as DRAY cannot individually target copying only one FILT location within a memory column to a position where it can be read. This is why the design to the left uses double the amount of FILT as the proposed newer design as this extra FILT is needed for both reading and writing. Using .life in conjunction with LBPHacker's "DRAY switching" technology would permit a singular PSTN access head that can read and write data to a single storage volume of FILT with only one pixel of DRAY, drastically improving the compactness of FILT memory designs.

Summary: 

• DRAY's .life is presently of no apparent or consistent/intended use.
• The position of the first pixel that DRAY will copy will be equal to (x, y) + .life * [a, b] where (x, y) is the position vector of the DRAY and [a, b] is the DRAY's propagation direction vector with normalized components.
• The position of the last pixel that DRAY will copy will be equal to (x, y) + (.life + .tmp) * [a, b].
• The position of the starting pixel of the destination will be equal to (x, y) + (.life + .tmp + .tmp2) * [a, b].
• The position of the last pixel of the destination will be equal to (x, y) + (.life + (2 * .tmp) + .tmp2) * [a, b].

Appended question: Does the SPRK element really have any use for its .tmp and .tmp2 properties?

Yes, I did read that supposed "equivalence" with CRAY and DRAY's tmp2, but that's only so semantically. CRAY doesn't undergo any copying/reading and first ignores .tmp2 number of pixels before adding elements. This is not the case with DRAY which first reads and then ignores .tmp2 pixels prior to "placing" the copy. So yes, to have "space prior to reading" (which I compare with CRAY's immediate "space before writing") would really help with FILT memories. Ah, and true. It would be quite something to have screens that double as "VRAMs" although it would require lots of DRAY switching.