Huz
After thinking about it again, I again stopped understanding what prevents the analysis of the log from continuing with the correct pattern number: when we start with the pattern number, then obviously the numbers in the pattern are not taken out of thin air or from the ceiling, and the program somehow calculates exactly what numbers should be in the pattern with the ordered number.
In the default case, where we expect to do the entire work in a single run, we start the recursion with an empty stack, and with the current batch number initialized to 0. Each time we advance the last fixed prime, we increment the batch number.
When we start a run with a specified batch, we do the same - start the recursion with an empty stack, and with the current batch number initialized to 0 - but when we advance the last fixed prime and increment the batch number, we check if this is the requested batch, and if not we continue as if we had already completed the work for this pattern.
When we recover, we do
not start the recursion with an empty stack, but initialize it to the state recovered from the last 305 line in the log. At this point we have no idea what the correct batch number should be, so it is still initialized to 0. As a special hack, if a batch (or range) was specified, on recovery we reinitialize the current batch number to be the same as the first requested batch number - that is enough at least to make it do the right thing for a single batch.
So to know what the actual batch number is, we should not start the recursion with an initialized stack on recovery, but start with an empty stack, and recurse counting the batch numbers until we get back to the point reached in the log file. That is a possible approach, but it involves quite a lot of new code with a lot of opportunities for new bugs; in particular, it would require a complete rewrite of the recovery logic.
The alternative is to include the batch number in the progress report (either by changing the format of the 305 line, or by emitting a new line), and then to rely on that to set the correct "current" batch number on recovery. This would require a lot less new code, but would need some care to ensure that it correctly handles both old and new log formats. It would also need care to avoid useless verbosity for cases where we may progress through thousands of batches in seconds.