This follows from discussion at: https://en.wikipedia.org/wiki/Wikipedia_talk:STiki#Pending_changes_and_STiki
Assume an article is under pending changes protection. An IP user then makes a vandalism edit. If another user with 'reviewer' permissions issues a rollback command via the API, then all the PendingChanges annotation seems to occur properly, as the editor auto-accepts his own version.
It doesn't work this way if the edit is reverted without using rollback. For example in Huggle, STiki, and other tools we simulate rollback in software for: (1) those that don't have the native permission, and (2) when doing "good faith reverts/rollbacks" that should not be marked as "minor". In these cases, a reviewer can revert a pending changes revision, but their change is not auto-accepted, and they sit in the review queue.
This speaks to the larger issue that PendingChanges works well in the browser where there is a well-defined workflow, but it can be a bit challenging to integrate with existing anti-damage tools via the API. (See also some concern about "multi-user pending changes chains" in the above link).
How this should be resolved is an open question. Could a parameter be passed at edit time to force acceptance? Could the software better recognize identity reverts and treat them consistent with rollbacks?