`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.)