I meant database consistency in the sense of never needing "repair tables"; although as far as I know, CouchDB's automatic conflict resolution is also consistent (based on UUIDs), isn't it?
They're not guaranteed to be the primary revision for a document (ie, the last write could be listed as the conflict) but the data is still there so that client code can resolve the conflict.
Also of note, if the edits that caused the conflict are replicated to other nodes, each node will independently choose the same revision to use as the 'primary' document response.
Bottom line, the choice is deterministic and is guaranteed to be preserved, but the choice may not be the last written revision.
Also, bugs that result in corrupt dbs are treated as major bugs as opposed to a part of the design. I've also not seen reports of index corruption under load, if you have logs or any more information we'd definitely appreciate if you could put that info into a ticket on JIRA [1] or even just mail dev@couchdb.apache.org with details.
Clarified it, thanks!