Sven Schüle wrote:..., and if I wouldn't ignore it then I would certainly not assume that some of the moves that belong to a time control session have already been played.
What else could it be used for?
So if I get a "level 40 X Y" then the number of remaining moves starts at 40 for me no matter what comes in setboard.
Yet subtracting it from the first session length does seem the proper thing to do. Unlike what Dennis claims the CECP specs say nothing about ignoring the full-move counter.
The point is that with WinBoard/XBoard it would never happen.Because when you start from a set-up position WinBoard would always store that as ply 0 or 1 (with black to move) of its internal game history.Soalthough its FEN generator faithfully writes the move counter, it will be based on the GUI's game history. Pasting the FEN back into the GUI would not (and cannot) restore that entire game history, and would be taken as move 1 no matter what of the new game.
So it is basically just a matter of GUI implementation, not of protocol. The WinBoard implementation happens to be such that it only would ever send FENs with full-move counter = 1. I expect most WB engines are only designed to handle this case.
Therefore, considering that Graham tested Jumbo successfully under ChessGUI (see his post above), I'm not sure whether we already know all about this problem ...
Actually I doubt that Graham starts from positions rather than opening lines. There are many WB engines that cannot load positions.
But there are many WB engines that also fail to count moves entered in force mode as belonging to a classical TC session. In fact that is a true epidemic. They show exactly the described behavior, expecting new time when they don't get it, leaving themselves without any significant time for most of the next session.