I originally treated the RPKI manifest number as something the publisher could derive when it started. That works until a restart causes the number to move backwards.
Relying parties do not know that a process restarted. They only see a repository which published manifest 41 and later offers manifest 1. Quite reasonably, that looks wrong.
The counter is now persisted and advanced with the publication state. Startup also waits for the first complete synchronisation before producing a manifest. Publishing early would be worse than publishing late: the manifest could honestly sign a partial view and then disagree with the objects which arrive a moment later.
The useful rule was that monotonic values are not decorations. If another system uses one to decide whether data is newer, it belongs in durable state.