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