Some quick background on merges and Apex triggers:

When a User merges Leads or Contacts, the merge losers are deleted and the
merge winners are updated with the fields chosen by the User in the merge UI.

The only way to detect a merge in Apex triggers is to trigger "after delete" on
the loser records and check them for the "MasterRecordId" field.  If present,
the record being deleted is a merge loser, and the "MasterRecordId" points to
the merge winner.

(this is all covered in the docs )

As stated in the docs, the losers are deleted before the merge winner is
updated with the fields chosen by the User in the UI.

So, let's say that I merge two Leads: Lead A ("a@test.com") and Lead B
("b@test.com").  In the UI I choose Lead A as the master record (winner), but
in the "decide between conflicting fields" UI I choose "b@test.com" as the
Email address to use for the winner.

Two DML ops happen:

DELETE loser (via merge)
Trigger.old = { LastName = "B", Email = "b@test.com" }

UPDATE winner (via merge)
Trigger.old = { LastName = "A", Email = "a@test.com" }
Trigger.new = { LastName = "A", Email = "b@test.com" }

However, if we update the winner during the loser delete trigger (the only time
we can detect a merge, remember) ... then something buggy happens.

Our application does exactly this, by detecting merges and copying the loser's

Email address into a custom "OtherEmails" field of the winner.  (this isn't just
arbitrary, there's a good reason for it).


So, during the "DELETE loser" trigger, we update the winner like so:

DELETE loser (via merge)
Trigger.old = { LastName = "B", Email = "b@test.com" }
{
// our custom trigger code
Lead winner = [select Id, Email, OtherEmails from Lead where Id = '<winnerId>']
winner.OtherEmails += loser.Email
update winner;
// this update of course fires triggers too, which would look like this:
UPDATE winner (via standard update)
Trigger.old = { LastName = "A", Email = "a@test.com", OtherEmails = null }
Trigger.new = { LastName = "A", Email = "a@test.com", OtherEmails = "b@test.com" }
}

The bug happens in the merge-driven winner update, where SFDC should be
applying the fields chosen by the User during conflict resolution.

The fields chosen by the User are simply gone.  They never get updated into the
winner.  Instead, an update fires that looks like this:

UPDATE winner (via merge)
Trigger.old = { LastName = "A", Email = "a@test.com", OtherEmails = null }
Trigger.new = { LastName = "A", Email = "a@test.com", OtherEmails = "b@test.com" }

 
The User's choice of "Email = b@test.com" is simply gone ... instead this
merge-driven update is a duplicate of the update that happen in the loser's
delete trigger.


What do I expect to happen?

This is a tricky situation, hence the title of this post.  With the present
order of operations - with the loser delete happening before the winner update,
and with the merge only being detectable in the loser delete, I can't think of
any good way to resolve conflicts between trigger-driven winner updates and the
user-selected winner updates.  A couple other changes may fix the issue:

1.  Update the winner before deleting the loser.

This way, custom merge logic (in loser-delete triggers) would be working with a
Winner that's already been updated with the User-selected fields.

Of course, this is a breaking change for implementations that rely on the
current behavior (though I don't see how they could), and there are probably
good reasons for the current order of operations that I can't think of but
which are obvious to SFDC's devs.

2.  Provide an actual "after merge" trigger that provides the losers & winners at the same time.

This "after merge" trigger would be just like an "after update" trigger (ie,
Trigger.old/new contain the pre- and post-update state of the Winners), plus a
new contact variable Trigger.mergeLosers that contains what you would expect.

Salesforce support - i have created case 05650893 to track this issue.