Reproducible on test:

• https://test.wikidata.org/w/index.php?title=Q211910&diff=525762&oldid=525761
• https://test.wikidata.org/w/index.php?title=Q211910&diff=525763&oldid=525762

Something is wrong with the edit conflict detection and merging..

Base revid is correctly passed to the API, so this is a backend issue.

The second api response (where the reference is overwritten) correctly says that the edit has been patched, but the patch results in the wrong final revision:

    "wbsetclaim":
    {
        "messages":
        [
            {
                "name": "wikibase-conflict-patched",
                "parameters": [],
                "html":
                {
                    "*": "Your edit was patched into the latest version."
                },
                "type": "warning"
            }
        ]
    }
},

@Lydia_Pintscher what would you say should happen in such a situation? Patch the edit and have both references or trigger an edit conflict?

Jakob and I sat down together last week to talk this through. Two take-aways:

• I seem to remember having related discussions and tickets with Thiemo. Pinged him to see if he remembers more details.
• The issue described here isn't just about references. Qualifiers are equally affected. And to make things worse the behavior is different for the main snak. We should probably align the behavior unless more insights turn up from Thiemo.

As discussed with @Lydia_Pintscher and @thiemowmde it should behave the following way:

• if two users add a reference/qualifier at the same time (= edit with the same base revision), they should be merged, and both references/qualifiers get added
• if two users edit the same reference/qualifier at the same time, it should get detected as a merge conflict

Technical Notes:
Edits made through the entity page UI via wbsetclaim do send a baserevid when making edits on statements. Looking into the SetClaim code I noticed that it currently deserializes the whole statement from the request and passes that into a ChangeOpStatement directly. I believe what it should instead be doing is to use a ChangeOpDeserializer to turn the requests into individual changes. Maybe that would already solve the problem.

Looks like it also happens if someone is changing the rank of the statement (example).