Actually, .tiepres will become what the other bot put into .tie, IIRC.
Correct me if I'm wrong
Your wrong in current versions. It used to be this way, back in the long long ago, but there was some argument made, perhaps by me, that the target bot should not have insight into the tying bot's tie naming conventions. So, *.tiepres for the target bot is essentially *.numties. When that tie gets deleted, it reverts to the previous tie port. I'm not really happy with this, since if a bot creates it's first tie by doing 2 .tie store and then gets tied to, *.tiepres will still be 2, but at least bots can use higher numbers for the ties they create and distinguish them from those created by others. Besides, using the tying bot's tie port has similar collision problems.
I've been thinking a nice addition might be a
pushties command that pushes all the tie ports onto the stack.
W.r.t. updating trefvars, the trefvars reflect the properties of the bot at the other end of a tie the cycle following when .readtie is set to that tie port. I.e. the trefvars will be updated the cycle following *.tiepres .readtie store. This cycle delay is exactly the subject of the recent suggestion I posted regarding in-cycle updating of control sysvars. Were I to impliment that, the trefvars would be updated immiediatly in-cycle when .readtie changes, allowing subsequent DNA to operate on the trefvars that cycle.