Thought I'd add some notes from talking with Damien & Aaron, where they're evaluating solution #1 is the current favored approach...
solution #1: Aaron is enhancing couchstore API so that couchstore can choose the right rev-seq, even for recreated items.
+++ Pros: no changes to the current 32-bit field in the couchstore file format. This would also move us from a per-vbucket level "highwatermark" design to a per-document level of req-seq tracking.
— Cons: changes to couchstore and to ep-engine.
solution #2: change from 32-bit field to 48-bit field in the couchstore file format.
+++ Pros: easy to understand this kind of change, so likely lower risk in implementing it.
— Cons: file-format incompatibility with 2.0-beta, so can't support in-place, offline upgrades from 2.0-beta to 2.0-GA. Also, changes to couchstore and couchdb.
solution #3: the math tells us this is unlikely to happen soon, as the seq-num is only updated at persistence-time not at item mutation time. That is, 400K ops/sec will not have 400K seq-num increments/sec. Instead, the req-seq # is incremented only when it gets through couchstore and persisted, so the speed of persistence limits the growth of this #.
+++ Pros: easiest to understand, as it's the do-nothing approach.
— Cons: this only delays the inevitable, as we still have to fix it, such as by implementing solution #1 in some ".next" release.
And, Aaron & Damin discussed doing both #1 and #2.
Finally, looking at the backup/restore code, it transfers the full 64-bits of rev-seq #, so it should be ok already.