I suppose it is worth pointing out that a 'revert' in git is just an undo update. The code history in Git is write-once. Git never deletes anything. So, in a revert update, based on the reverted change: any lines that were added are removed, and any removed lines are re-added. So, a revert is a new update, it just an inverted update to cancel out a previous one.
Revert PRs are not at all special to Git, it's just another update. Once a revert is merged, a person can revert the revert update, add more changes to it, and then merge all of that as one bundle.
So, a flow might be like this (the letters on the left hand side represent the commit ID, AKA the commit SHA):
a43ae Some update that introduced a bug
3ads2 Revert: Some update that introduced a bug
fae54 Revert: Revert: Some update that introduced a bug + Bug Fix
Changes to the code base are "squashed" together. When a person clicks the revert for the revert, that creates a new proposed change. Bug fixes can be added to that proposed change, then it'll all be squashed together as a single commit that is then released.
For example, when reverting the revert, this change would be proposed:
abc12 Revert: Revert: Some update that introduced a bug
In that proposed change, we can add the bug fix, eg:
abc12 Revert: Revert: Some update that introduced a bug
fea23 Bug fix
Then, when merged, that would land on the main branch and in the history as one commit, eg:
fae54 Revert: Revert: Some update that introduced a bug + Bug Fix