It seems that the postBatchResumeToken (PBRT) that is returned in responses to change stream getMore requests is currently not updated if the getMore responses do not include any documents *and* the change stream cursor has not yet reached the oplog tail.
In this case, the getMore responses always return the same PBRT value, before either a matching document is returned or the change stream cursor is at the end of the oplog and the high water mark gets updated.

Not returning an updated an updated PBRT is problematic in case when there is a large backlog of oplog entries to scan by the change stream cursor, there is a match expression that filters out all/most events and there is only a limited amount of time available before the stream gets invalidated.
For example, we found such case in an internal test that executes stepdowns of the primary every 8 seconds, and in which getting to the tail of the oplog with a single change stream cursor takes longer than 8 seconds. The slow scanning here is likely due to the test running under UBSAN, but in theory the problem can also happen without it.
Once a stepdown occurs, the stream is aborted. The test then retries and reopens a new change stream cursor at the same operation start time as the previous one. As none of the getMore requests returns an updated PBRT, the test has no chance to make incremental progress: it always needs to restart at the same oplog position and will never manage to get to the end of the oplog within the available 8 seconds.
It would be beneficial here if the getMore responses returned an updated PBRT value every now and then, so that even when the scan has not reached the end of the oplog, the consumer of the change stream could take note of the updated PBRT and resume from there in the next attempt.