[sorry. replied earlier incorrectly]. one of the two transactions would abort in this case. snapshot isolation needs to check that any data mutated in the transaction were not also mutated externally. in the example you are replying to, there is no mutation, and so no problem, but in your example there is. see http://en.wikipedia.org/wiki/Snapshot_isolation

note that it's only mutated values that are checked for conflicts, and only against other mutations (this is why it is efficient - the number of checks required is small). so you can get weird behaviour when multiple values are read while different transactions change each - there's a good example in the link above. this is called "write skew".

the whole approach is, in a sense, exploiting poor phrasing of the ansi sql-92 standard, which doesn't actually require serialisation even though that is the most natural way to interpret it (as far as i understand things). so you can think of MVCC as "exploiting a loophole" that leads to a more efficient system, but one that is less intuitive. on the other hand, this is not new - it's already the standard behaviour for postgres, oracle, sql server, etc.