Currently, RTS uses the checkpoint snapshot to revert any updates that are written to the file only for the non-timestamped tables. It doesn't use the checkpoint snapshot on timestamped tables as they will be handled using the commit/durable timestamp. As it is believed that the commit/durable timestamp from the newer transaction should have a timestamp that is greater than the stable timestamp.

It is possible from the API that a transaction can commit with a timestamp that is less than stable timestamp when the transaction timestamp was set using two different API calls.

It would be better RTS handle any such scenarios by verifying the updates with checkpoint snapshot.