<hr /><i>drh added on 2011-08-30 14:22:37 UTC:</i><br />
Whether or not this should be reported as a conflict is a matter of
opinion.  Technically, whenever two people make any changes to a file
in parallel, the resulting merge is a conflict.  We <i>choose</i> not
to report conflicts that can be cleanly joined together.  For example,
we choose not to report conflicts when the two edits are in different
parts of the same file.  Just because two edits happen to merge together
cleanly and without overlap does not mean that the resulting code will
still run, after all.

Even edits in separate files are potentially a conflict, since while both
edits might work fine separately, their combination might make the software
fail.  So, technically, any parallel change to the project is a conflict.
But we choose not to make a big deal out of most of these conflicts since
most of the time they are benign.

The tricky part in a merge algorithm is to identify and announce conflicts
that are likely to require programmer intervention and resolution, versus
conflicts that the software is probably able to deal with itself. You don't
want to announce too many conflicts, because - as with the boy who cried
"Wolf!" - users quickly develop conflict-fatigue and end up ignoring real
problems.

In the case of an edit/delete conflict, the software currently thinks 
it can deal with that itself.  If you want to disagree, then give us
some specific cases where that policy causes issues and argue your case.
In the absence of a more compelling rationale, I don't think this complaint
warrants any changes to the current merge logic.