This can be implemented with undo, but a much better solution is to have a genmove command which doesn't imply that the engine automatically plays the move. This is how gg_genmove in GNU Go works and I have a feeling that maybe we should change the semantics of the genmove_white and genmove_black commands to get this behaviour. The drawback with this proposal is that in normal operation the driving program would have to echo the result from a genmove_black command in a black command to execute the move (and likewise for white moves).
I don't think that would work for some of the things I have in mind. I want to be able to generate positions a few moves down the move tree then go back to the original position.
No, this doesn't require anything extra in the protocol, only that the GUI keeps tracks of the moves that have been made. The "black" and "white" commands suffice to set up a position.
In order for the client to regenerate the position it has to choose an order to replace the stones on the board, and if there is a ko on the board it has to be careful that this order leaves the ko in the right state. Better just to have undo available.
I think undo is simple enough to implement that it is not a big imposition on programmers to make it part of the protocol. So I agree with Don.
Did you look at my undo patch? Does it seem OK?
Dan