When it comes down to it, I struggled with movement rules because it was originally written in such a restrictively dedicated manner that shortcuts past the way I would THINK we would want to have the code consider it so that other rule options could be introduced - my point being that I was trying to modify an existing structure that was not only complex but clearly not intended to be adjusted to this sort of depth of interaction. I got the sense that it would almost be better to rewrite movement rules from scratch but that the complexity of it left far too much room for much worse error to attempt it.
That said, I'm pretty sure I found some other erroneous spots and corrected them but apparently introduced some new ones. It's a mess indeed. I presume the main problem here with the delay is that there's simply too much evaluating of what can or cannot be seen and interacted with going on because it's taking place more at a unit by unit level rather than a player level. Very frustrating. Initial tests actually showed a speedup after these changes, probably due to some of the things corrected, but I wondered if more complex games, if clocked, would show slowdowns, perhaps dramatic ones, instead. Apparently what I was afraid of was correct. My apologies.
Keep in mind as you look into this though that I was hoping to set us up for more interesting things than simply tunnels - I wanted to make it possible to have a number of individual reasons that units that would be able to see each other and be hostile towards each other could still overlap without combat.