Its not, its still read committed. Its the same thing as if you had to read from two rows in a transaction, and your isolation was read committed, and both those rows would be modified by a different transaction. Its possible you read the first row, a transaction is committed and then you read the second row with the updates from the transaction. You have just read a partial commit. It is ACID and it is not serializable, the thing is MySQL lets you use higher levels of isolation like repeatable read or serializable which are very useful and today Vitess can't guarantee that in a 2PC.

The data will be committed, but you may get a subsequent read that has the previous value, before it is overwritten by the final value. This would only occur if the shard where the commit is occurring fails, while the promoted shard replays the transaction before the final commit is propagated to the user. Since the shard as failed is impossible for a single transaction to experience this behavior, but an outside observer would be able to see this behavior. Transactionally everything would still be isolated, but outside the transaction you would see behavior you won't expect.