As discovered in ergoplatform/oracle-core#173 :

In their votes, an oracle must specify the reward token amount in the pool box when the update-pool command is initiated. So if the update-pool command is not planned to run in the current epoch, the oracles have to estimate the reward token amount in the pool box in the upcoming epochs. Since the reward tokens are given only to the posting oracles whose data points are within the deviation range, it is pretty hard to precisely estimate the reward tokens amount in the pool box in a few epochs, let alone the next day. This effectively makes the whole prepare-update, vote-update-pool, update-pool process to be run in the shortest time possible, ideally within one epoch. I foresee this would be challenging in a decentralized environment.

What if we request the reward token id and amount from voters and check that the new pool box has it only when a new reward token is minted? Otherwise, check that the reward token is preserved in the update contract.
The whole check could be expressed as "reward tokens in the new pool box should be preserved (poolIn==poolOut) OR exactly as voted for (reward token id and amount in ballot box registers)".