What I mean is the standard resolution as implemented in
Darcs.Patch.Conflict.mangleUnravelled: unless the input consists only of
hunks, it simply takes the head of the list. In other words: pick any
version, whatever comes first.

You can see that when you pull 'addfile ./x' into a repo with 'adddir
./x' (see issue2548 for what else goes wrong when you do that) using
--mark-conflicts: for darcs1 it gives you the directory x, for darcs2 it
gives you the file x. Neither is a good solution: it should instead
produce the equivalent of the usual "conflict markup" in the file
system. That is:

The standard conflict resolution for name collisions (add or move with
the same target path) should be (pending) moves for *both* to some not
yet existing name. For instance, if the target is "./path/to/thing",
then I would like to get ./path/to/thing.~1~ and ./path/to/thing.~2~ so
I can properly compare the two and chose one or create a mixture of both.

(Ideally, instead of increasing numbers, we should append the hash,
perhaps suitably shortened, of the named patches that contain the
conflicting prims. This is a different issue, however, as it pertains to
hunk conflicts in very much the same way.)

This is probably best deferred until we have a new patch format (with
camp-style conflictors); the calculation of conflict resolution markup
is pretty messy and we probably have to re-write it anyway.

Maybe the situation described in the first message is a consequence of
the fact that Darcs captures and expresses conflicts only as
modifications of the working tree.

It Darcs had another place to put this data, say some file
_darcs/conflicts , and a more interactive and detailed UI for whatsnew
in case of conflicts and mark-conflicts, we probably would be able to
give to the user the complete explanation of what conflicts are
currently happening in their repo.

Yes, an extra file with detailed explanations about conflicts would be a
good addition. Needs a bit more detail (file format, syntax).
 
I still like the idea of getting "markup" in the working tree itself,
i.e. rename both to new versions inside the tree, with some special suffix.

We can do both, of course.

I have a partial solution along the lines indicated by gh. Instead 
of taking the head of any set of conflicting alternatives that we 
cannot mangle (turn into working tree markup) yet, we return the 
unmangled alternatives along with the mangled ones. In the affected 
commands we output a warning and display these alternatives. I think 
this is a strict improvement over what we have now. Will send a 
patch.

The following patch sent by Ben Franksen <ben.franksen@online.de> updated issue issue2550 with
status=resolved;resolvedin=2.15.0 HEAD

* resolve issue2550: apply only properly mangled resolutions, warn about any others 
Ignore-this: f63dd3fe64a45fde5ce550734183b63968e968390625870fbd2bb944f87ede1cea563a6ab84c34f8

To support this change we add the new data type StandardResolution and
return that from standardResolution. It contains a summary of the data we
gathered from calling resolveConflicts: the mangled resolutions, merged into
a single FL, the list of conflicted paths, and an IO action to warn about
and display any (unravelled) conflicts that we couldn't properly mangle. The
warning is normally only displayed if we actually want mangling to happen
i.e. if --mark-conflicts is in effect (except for the mark-conflicts command).