I think that the tmp of EDIT should not carry over to the affected particles. There are only a few particles that use tmp, and I have a more useful proposition for the tmp:

If the tmp is zero, then it instantly transfers all of it's properties (excluding tmp).

If tmp=1, then it is relative (say EDIT's temp is 30, then it will add 30 to the temp of the affected particles.)

2: only transfer type (allows EDIT to replace CONV).

4: only transfer ctype

8: only transfer temp

16: only transfer life

32: only tmp2 (maybe transfer to target pixel's tmp?)

64: only vx (EDIT will not move from vx or vy)

128: only vy

256: only dcoulour

You can also combine them: Say you want to add 15 vx and 800 temp. Just make a pixel of edit, set it's vx to 15 and it's temp to 800. Then, set it's tmp to 1 (for the relative) + 64 (for the vx) + 8 (for temp) = 73. As simple as that.

All in all, I think that this element would make an excellent addition (or, replacement of CONV) to TPT.

EDIT (Not the element):

512: changes to multiply/divide. If it was a relative (has the flag 1 added in), and you add 512 to it, it becomes multiply if it was add (+0, or even numbers), and divide if it was subtract (+1, or odd numbers). From our previous example, 73 is add vx and temp. if we add 512 to that, we get 585, and it multiplies it's vx and temp with the target pixel's and sets the target's vx and vy to that.

Also, perhaps a switcher element (SWCR), that uses similar flags to switch properties (tmp= 64 [vx] + 8 [temp] = 72 would switch the vx with temp). Not sure how this would be useful, but it sounds cool to me.

I can't imagine why, but some day someone will want to change the tmp of a non-tmp-using particle.