I debugged the problem a little bit.
The reason why the merge is done that way, is that there is an ancestor lookup before 
the actually merging the files, based on their filectx/sha1. As file 'a' has the same 
sha1 in 1 and 3 (in the small example from benoit) the ancestor lookup stops with 
revision 1 as the ancestor (even though  the correct one would be 0). The file in rev 
1 has the content ab, which is the same content as in rev 3. As rev 1 is taken as the 
base content, the merge assumes that the content from 3 must be older then the one 
from 2, as it matches the base content, therefore the content of file 'a' in rev 2 is 
taken (which is a).

I guess the right way to fix this, is to go on with the ancestor search until the 
changeset ancestor is reached and take the 'latest' filectx ancestor.