I had a misconception about couchdb's conflict management. I was under the impression that couchdb handles document deletes in the same way as document updates. In fact a delete creates just another revison that marks the document as deleted, also known as the tombstone revision.
When a document gets modified after replication, on both databases (source and target), and the document gets replicated again from source to target, it will be in conflict state. This is also true for a document that has been updated on the target and deleted from source. The document's tombstone revision gets replicated, but as couchdb's way of resolving conflicts is to 'delete' the unwanted revision, the just replicated tombstone revison is implicitly considered as the unwanted (or loosing) revision in this conflict. So the conflict is implicitly resolved by picking the revision that has not been deleted. The document in the target db doesn't show any
_conflicts field but it shows the replicated tombstone rev in the `_