After some research the only explanation I can give is this is due to the position where the search started was overwritten with some deeper searched position in the transposition table. Hence the position can not be found when we traverse the transposition table for the principal varation. And since the 'bestmove' sent to the interface is dependant on the first move in the principal variation, no move is sent.
I hoped the depth/new replacement scheme would take care of this, but in retrospect this hope was futile since the second entry (the 'new' entry) is replaced very often.
In the upcoming version of Mediocre I have added a searchRoot-method that only handles root nodes (that is the first set of moves the engine has to choose from and of which one will ultimately be played). This method is called from the iterative deepening loop, and from here it calls alphaBeta for every root move.
This way we will always know what move was chosen as the best, and we can base the principal variation output on this. Now the worst thing that can happen to the pv-output is we only get the best move and nothing more (instead of best move plus the rest of the expected line), this should happen very rarely (every 20th game or so as mentioned) so it is no big deal.
There are also other benefits to be gained from this approach, since the root is only iterated 30-35 times on average (the number of available moves) we have room for things like more advanced move ordering, reporting the currently searched move etc. Anything we do here will have little effect of the overall performance of the search.
Also we should not probe the transposition table at the root node to check for cutoffs. I have done this before, but all we are interested at the root node is what move to be played.
So all in all this change was needed, and hopefully the annoying bug is gone for good.
Winbord force mode
The winboard protocol clearly states that when the 'new' command is sent, the engine should exit force mode. I simply overlooked this and therefore Mediocre has not been able to play to games in a row if it is black in the second game. This was only noticeable under certain circumstances though since some interfaces handles this more loosely, and also restarts the engine after a game.
However, when a new game is about to start the winboard interface sends:
newI am not entirely sure what the point of the force command there is, but probably it has something to do with preparing the engine for any possible starting moves that might come.
Anyway after this the interface sends 'go' if the engine is white, since it should move, but only 'usermove [move]' if the engine is black.
So it is imperative we exit the force mode on the 'new' command, or else the engine will only play the 'usermove' on the internal board, but not start thinking about an answer.