From what I can understand of the resolve command (and some simple experiments)
it is unrelated. The problem is (wildly) incorrect merges which are committed
and pushed to the server, and only noticed hours or days later, usually after
many other changes have been made on top of them.

I have not seen a bad merge of the type I formerly saw routinely in a while, so
perhaps the fix of Issue1049 really worked. (I think most of our developers have
upgraded to Hg 1.0.) Still on occasion see other inexplicable mistakes, such as
a large set of files (unrelated to the culprit's real work) being truncated to
zero length during a commit, but I don't think these are related and would
probably not be caught by this kind of hook anyway. Downgrading therefore.

Will the new resolve command help address this?

Not sure yet; at least urgent. Just had to fix up a bad merge today (spuriously
deleted the bodies of a number of files while not removing them), but I have not
heard back yet what version of Hg the author was using or any other details.
Another recent bad merge seems to have been made using 0.9.5, though I did not
get a satisfactory explanation of what happened yet.

How important do you think the need for this is now, given that it's no longer
possible to accidentally commit a single file after a merge?  I can see that
it's still necessary, just wondering if it can be downgraded from critical.

Since there is no apparent easy way to fix a completely wrong merge (generally
one which accidentally reverted other work) - see Issue1010 - and it is hard to
even notice such merges in a big team - see Issue981 - and the Hg UI is such
that it makes them likely - see Issue28, Issue1011 - it would be very valuable
to able to reject such merges before they can be pushed to the server and cause
harm.

Roughly:

1. When receiving a merge changeset, simulate doing the merge of the two
parents. Note any textual merge conflicts (not just quiet successful merges of
noninterfering changes in the same file), as well as miscellaneous conflicts
(e.g. edited but deleted, renamed twice differently).

2. Collect the diff from the actual merge changeset to the simulated merge.
Discard any diff entries for files which were actually in conflict as previous
noted.

3. If the discrepancy is too large - say, expressed as a percentage of the sum
of the sizes of the diffs to each merge parent - assume the merge is bad and fail.

There is a risk of false positives coming from someone doing a genuinely
complicated merge of semantically conflicting changes. But in this case you can
probably do a quick merge first, resolving any textual conflicts and committing,
then going back and checking for semantic conflicts: making sure all files
compile, tests pass, ad nauseam. This is perhaps easier to understand in later
history later anyway (in the absence of Issue981).

There probably needs to be an override mechanism for experts to push a merge
which intentionally does something unusual, such as "capping" a dead branch, or
in fact recovering from an older bad merge.

Sample bad merge which would be rejected:

http://hg.netbeans.org/main/rev/d54bd12bad21