Specify merge manually

How would this differ from the current behaviour when Diffuse is launched with the following command lines?

$ diffuse localfile outputfile otherfile
or
$ diffuse localfile outputfile otherfile basefile

Should the pane layout be different? Currently Diffuse treats all panes as equal peers. Merging into the second pane is simply convention. Should singling out outputfile with the "-o" switch give it any special behaviour?

I really like using Diffuse as my diff tool because of the nice syntax & diff highlighting. I would like to use it as my 3-way merge tool as well but it seems Diffuse is not setup to do this. Perhaps it was never intended to be used this way? If you want to expand Diffuse's functionality to do traditional 3-way merges my suggested changes are below:

Typically input files are read only, which means no save buttons on input files, only output is editable. The output file is usually put at the bottom and spans the whole width of the window, See:
http://www.perforce.com/perforce/products/tours/merge/p4merge_three_pane_1.html
or
http://www.scootersoftware.com/images/TextMerge.png
or
http://kdiff3.sourceforge.net/doc/screenshots.html

-Merge conflicts should stand out from diffs which were automerged into the output file by the VCS
-It should be easy to jump between the conflicts before and after resolving them
-Ability to resolve a conflict by choosing a line from an input file or multiple lines from two or more of the input files in any order
-Diffuse should not allow you to save the output file or close the program until all conflicts have been resolved
-Conflicts should not be attempted to be resolved automatically, ie put "merge conflict" in output file initially

This is actually a very good suggestion for making diffuse a preferred tool for use with version control systems.

Typically (at least in my experience) the version control system responds to a merge conflict in foo.c (for text files) by creating three scratch copies of the file: foo.c.THIS, foo.c.OTHER and foo.c.BASE (or similar). BASE and OTHER are read-only. The human-driven merge tool (in this case diffuse) would treat THIS as the destination and *optionally* copy THIS to the original foo.c in the working tree. If the changes made to foo.c actually resolve the conflict, the vcs will then be able to do the merge. (If the human goofed, then he gets to try again.) The nice thing about this system is that the user's working tree copy of foo.c gets touched only if he says so. So it's super-easy to change your mind about how to resolve a conflict with no extra risk to foo.c.

Just noticed diffuse because I am looking for something that is as convenient to use on Windows as "xdiff" is on UNIX. For basic 2-way use diffuse seems to do the job nicely. 3-way merge is OK, but could be better. Other tools which offer 3-way merge (including xdiff) have an option to automatically merge non-conflicting changes. This requires one of the files to be considered the "base version" either explicitly or by convention; then for each diff region, if only one of the other files differs from the base version, that file's contents are selected for inclusion in the output file.

(Mentioning this here instead of as a separate enhancement request due to dtmoser's comment: "Currently Diffuse treats all panes as equal peers. Merging into the second pane is simply convention.")