It's an interesting idea, the first time I have heard of it. :)
One potential problem - apart from quirky areas - is how to know the opposite of a direction. Currently speedwalks let you specify the inverse of any direction, except the standard ones (eg. N -> S, E -> W, up -> down).
At present MUSHclient only stores the forwards direction in the speedwalk queue, as it doesn't need the inverse direction for walking. However to merge speedwalks like you describe you would need to compare the "end" of each queue to see if the end of one was the inverse of the other, and if so, cancel them out.
Ways I can imagine are:
- Storing the speedwalk inverse directions in the speedwalk queue, and using that to work out whether to cancel one.
- Using reasonable defaults (eg. N -> S, NE -> SW and so on), stopping when it can't do it any more.
- Having user-configurable inverses (eg. for the world) - however I think this might be unncessarily complicated.
The problem with the first option is if you throw in some standard moves between speed walks - the inverse might not be known. I favour the second option myself.
Naturally you would have a world option as to whether or not it attempted to do this - as Meerclar says, you may not want to.