What does non-runtime-atomicity of Marble::write_batch imply?

[vi]

This function is crash-atomic but NOT runtime atomic. If you are concurrently serving reads, and require atomic batch semantics, you should serve reads out of an in-memory cache until this function returns.

• Does it still guarantee that value returned from Marble::read for any key during Marble::write_batch would be either pre-write_batch or post-write_batch one, not an "out-of-thin-air" value or a "teared" value with a first half of the buffer old and second half of the buffer new?
• If yes, can a value intermittently turn None before switching to the post-write_batch one?
• If no, can it also temporarily disturb unrelated keys (not mentioned in write_match)? What worst can happen from an attempt to read an entry that is being modified?

[spacejam]

previous db:
1: a
2: b

write batch sets these to:
1: x
2: y

then it is conceivable that reads concurrent to that write batch could observe either a or x for 1, or b or y for 2. but no tears. no unrelated keys are impacted. None can not be returned for reads that begin after the initial values are written.

that said, I'm hacking on a simple MVCC implementation today that might avoid this confusion completely.