Generalized Summary field. After patch there can be .rej, .orig and the file with partially applied changes. Merging
tool using these three files would help a lot.

I've been looking into this:

When Mercurial does the Import Diff, it tries to do an automated merge using the input from the specified Patch file in
standard diff format.

"If patch cannot find a place to install a hunk of the patch, it writes the hunk out to a reject file (see Reject Names,
for information on how reject files are named). It writes out rejected hunks in context format no matter what form the
input patch is in."
http://www.gnu.org/software/diffutils/manual/html_mono/diff.html#patch%20Input

Looking at the code in place to do the Resolve Conflicts in ResolveConflictsExecutor, you can see that it is taking as
input a diff file generated from an attempted merge and splitting it up into the various diff portions to allow the
Resolve Conflicts UI to display the parts in conflict for the user to choose.
The problem with the .rej files is that they have been rejected by this merge process and so may or may not have a
location which makes sense to merge them into.

The simplest and safest approach is to diff the orig and new file that may have some hunks already successfully merged
and then look at the .rej file to see roughly where you need to put the changes and then do so by hand.

I cannot see any straightforward way to modify the ResolveConflicts code to handle .rej file as input which would be
reliable. As the above quote says the Patch tool has rejected the hunk because it couldn't find somewhere sensible to
put it.

Update from the Unofficial Mercurial Dev Guide:
================================================
Strategies for applying a patch:
http://hgbook.red-bean.com/hgbookch12.html:

Exact Match with context, line numbers and text: Hunk applied.
Exact Match with context and text, ignore line numbers: Print out offset from original line number.
Reduced context and text: Print applied hunk with fuzz factor.
If none work: Hunk rejected, unmodified file saved with .orig, copy of file with hunks that did apply and .rej with
rejected hunks.

Handling rejection:
Unfortunately, there aren’t any great techniques for dealing with rejected hunks. Most often, you’ll need to view the
.rej file and edit the target file, applying the rejected hunks by hand. There is an experimental tool that might help
called mpatch.

The mpatch command can help with four common reasons that a hunk may be rejected:
    * The context in the middle of a hunk has changed.
    * A hunk is missing some context at the beginning or end.
    * A large hunk might apply better—either entirely or in part—if it was broken up into smaller hunks.
    * A hunk removes lines with slightly different content than those currently present in the file.
mpatch enforces double-checking the tool’s output, by automatically dropping you into a merge program when it has done
its job, so that you can verify its work and finish off any remaining merges. 

Will investigate mpatch and see if we could launch it or set it as the default patch tool, so if .rej files are
generated we'd launch a 3 way diff tool if available to help manage the rejects.

Location of mpatch: http://oss.oracle.com/~mason/mpatch/mpatch-0.8.tar.bz2

Looked into mpatch and as its python code will run on the supported platforms. The problem is that it does not generate
the  type of forced merge with diff inserts that I'd need if we wanted to use the internal Resolve Executor in the plugin.

Closing this with no plan to fix and release noting the issue with details about mpatch if folks want to run this
externally.