Under the current node revisions overview logic, it is possible for a page of the revisions listing to show no revisions. This is confusing.
The NodeController->revisionsOverview() method reads in all revisions of the current node, and then filters them down according to whether the revision in question has a translation for the currently active language, and whether that revision translation is 'affected'. This was done in
#2465907: Node revision UI reverts multiple languages when only one language should be reverted →
to address the issue of the revision UI reverting multiple translations when it shouldn't be.
Because the paging of the revisions query doesn't account for language and 'affected' state, it is possible for the revisions query to return a set of revisions for a node of which none of the revisions belong to the language being tested, nor are any of them marked as 'affected'. This filters the list down to zero, which results in an empty table of revisions for that page, which is confusing.
It's possible for this situation to arise on a site with many active languages. Given a site with 55 languages, if a node goes through translation, and there is a new revision for each language that is translated, it would be very possible for a given page of revisions to contain no revisions eligible for display.
The logic which filters down the returned page of revisions to the current language and 'affected' should be able to be pushed into the revision query itself (NodeController->getRevisionIds()). Since this is a protected method not called anywhere else, it should be safe to add these conditions to the query, to allow the pager to function properly.