Hmm, in fact, this may work seamlessly actually. (I deleted this post before because I thought it was nonsense but it seems I was wrong)
For pondering, one would simply use go wtime ... btime ... from previous move.
There are two possible scenarios:
1) the engine finishes search before ponderhit/pondermiss; in this case the GUI would simply remember the move (best/ponder) and wait for the opponent. Then if it is a ponderhit, play immediately. If not, do a normal go wtime ... btime ... after opponent moves (pondermiss continuation)
the advantage is that you even save CPU resources this way except that you won't be able to "ponder more"
2) engine still searches when the opponent plays a move:
- if it's a ponder hit, the GUI waits for the search to finish and continues as in the case above (the GUI knows it's a ponderhit not based on PV but on the move the engine is pondering on)
- otherwise it was a ponder miss, the GUI sends a stop, waits for bestmove, discards it and does normal pondermiss search as above
So the only thing that'd be necessary to do is to stop the search when the engine receives a stop command - I think all engines have to handle correctly anyway due to timeout check.
So you were right, it should be possible and actually quite easy to implement. The only drawback is the engine won't spend more time in the case of a "ponderhit" before the opponent makes the move; one could start the infinite search now but I think it may be dangerous so I'd simply prefer to wait for the opponent to move;
or maybe alternatively the GUI might even already start another ponder search on the next ponder move, but it would be trickier
for the GUI, because this second ponder search may still turn out to be a pondermiss on primary ponder search.
In the extreme case the engine might be pondering up to n moves, this seems a bit weird.
But I still think something like this might actually work very well if done right (only problem again would be how to adjust TC).