It seems that if you prepare a transaction that used multiple commit timestamps, all the updates are forced to the last-set commit timestamp at prepare or commit time (haven't checked which). This seems likely to result in missed conflicts or other consistency problems.

Note that you have to set the prepare timestamp before you set any commit timestamps, but this can easily be done with timestamp_transaction().

I have a test that exhibits the unwanted behavior which I'll attach. It's currently set up to expect the current behavior rather than the expected behavior, but this is easily changed in the obvious way.

Note also that currently you can set the durable timestamp to anything after the last commit timestamp set; this is ok when that's the commit timestamp used, but problematic if other updates in the transaction have later timestamps. The test exercises this as well.