Navigator.go vs revertToLastRoom in context of no link and a "bloker" trigger

[lamvak]

I added a "bloker" trigger for "Nie widzisz zadnego wyjscia prowadzacego na (.)." for Arkadia ("You see no exit leading (.).")
This leads to a curious problem.
Navigator.go will simply and silently ignore command when there is no link from the current location in the requested direction. That's fine, unless we add said blocker, which (with standard tf bindings) calls for revert, that'll take us one step back. No step was taken, though, so no step should be recalled. That moves the dot actually back one step too far. A solution for this problem might simply be - not to use such a blocker.
On the other hand, that blocker would do great in places where there would normally be links on the map, but those links wouldn't always work. And with Arkadia we have a good example of usefulness of such a blocker: the meadows in Bretonnia, where links are removed at random at each boot. If the blocker would work well, the dot wouldn't get lost there.
Only for proper functioning of this kind of a blocker - such that can be triggered both on an actuall link and when there's no link for requested direction - there must be a distinction between ignored and executed steps.

[lamvak]

One thing that could be done is to replace revert with revert-if-moved. That's quite obvious.
It might break, though, with a slow connection. Lest say there are three locations A, B and C connected as follows:
[A] - [B] - [C]
Player starts at A and hits e (or numpad 6) twice, fast enough so that his actions are performed before MUD has a chance to answer. Without recognizing responses for each actual step and providing them to mapper there is no way to distinguish between a block on B and a block on C - did the Player actually reach the C room?

On the other hand mapper (in coordination with the binding) could wait for a response and move the dot only after a positive response has been received. That might work better for tracking the position. But then, should the Player be allowed to issue walking commands when waiting for a response? Those could be just sent to the server, or queued. If queued - should the queue be emptied on first block, or simply replayed (possibly allowing the Player fall from a cliff ;) )?