GRANDPA Pause/Resume have not been implemented in the substrate client code, therefore I would hold on implementing those for now.

To answer your question though I think that only a single Pause / Resume message would need to be tracked per fork since these would be enacted based on block depth (similar to forced changes) rather than based on finality. Since these would be enacted based on block depth I think they wouldn't affect the next_change rule, e.g. by the time we should be voting to finalize that block we would have already enacted the pause.

GRANDPA Pause/Resume have not been implemented in the substrate client code, therefore I would hold on implementing those for now.

We need to track multiple pending Pause / Resume signals per-fork, like we do for standard changes. Otherwise if finality is halted and there's a pending Pause / Resume signal, a further one being issued would make it impossible to import such a block and halt block production as well. We might be able to get away with just refusing to import a block that triggers a Pause while there is still a pending one, but e.g. if the pause is being triggered by an automated process (governance), then this could lead to the death loop explained earlier. It's also important to make sure we don't enact a Resume (on block depth) before the corresponding Pause been enacted (on finality). In that case next_change should also consider the earliest pending Pause when voting to finalize.

(Edited my original response significantly in light of your comment.)