If you configure a job with a module list, polling should not trigger a build
just because an incoming merge changeset mentions a file contained in one of the
modules. The list of files "modified" by a merge changeset in Mercurial is
generally meaningless (which is why it is not displayed in the changelog page);
someone merging changes made to an old parent rev with a new head will often
produce a merge that claims to "modify" completely unrelated files which were in
fact changed by other people in the other branch.

(The "modified files" list for a merge changeset will always include files that
were actually merged, but often includes other files that were simply picked up
as-is from one or the other parent. The exact behavior seems to be a deep
implementation detail of Mercurial with little significance to the SCM user.)

Example: http://deadlock.netbeans.org/hudson/job/javacard/10/changes shows only
http://hg.netbeans.org/main/rev/c487f4093cf5 which was a routine merge made by
someone not working on javacard.* modules. The build therefore ran even though
no changes were made to any files matching the javacard.* pattern.

Even if the merge is nontrivial (i.e. required conflict resolution of some
kind), and some of the resolved files were in the module list, it is very likely
that it is one merge parent is a descendant of some regular changeset which
modified those same files. Since the Hg plugin only deals with a single branch
for a given job, either that regular changeset was already in a previous build,
or it is coming it for the first time in this build - which would trigger a new
build from the polling anyway.

The only scenario I can think of where suppressing the file list for merge
changesets would cause a build to not be triggered by polling when it really
should be triggered (i.e. a pull & update will really cause some files in the
module list to be changed relative to the previous build) is as follows: you
modify file A in one changeset "a", modify B in another changeset "b", merge "a"
and "b", modify another file "C" (even though there was no line-level conflict
in it), commit the merge as changeset "c", finally push to a repo where some
Hudson job is listening for changes in "C" only. This seems like a very unlikely
scenario: most file edits in a merge are done only to resolve "hard" conflicts.
Once in a blue moon you might modify some file closely related to one that was
merged to avoid a semantic conflict (such as compilation error), but this is
likely to be in the same module. Anyway most of the time you would only notice
such conflicts to begin with, fixing them as a regular changeset, because a
Hudson build failed - so polling based on merges would not be helpful.