@haraldme: the devil is in the "something closer to" details. Please read my original comments. There are two basic problems to solve:
1. Dealing with workspaces not using a cache repository. In that case the remote head, i.e. the proposed new tip of the workspace, is not locally available, so a plain call to hg diff or the like will not work. If you have already run hg incoming and thus saved a bundle somewhere, it may work to use the little-known "bundlerepo" syntax: hg -R incoming.hg ... will run on an effective repo consisting of the current (workspace) repo plus the specified bundle.
2. Figuring out what command to run to actually get the list of files changed between two revisions. You need to know the exact list, so you can filter by the modules config option (if defined) and check to see if there are any files left. hg diff --stat, available in recent Mercurial versions (but not older versions), gives a decent summary for people but is difficult to parse mechanically. It also does not show file renames meaningfully. hg status --rev gives much more parsable output but wastes time walking the working copy and will in fact mix in junk if there are any local modifications in the workspace (from a poorly written build script) and the clean flag is not set, since unlike diff it only takes one revision argument. The best approach I can come up with is to run hg manifest --debug --rev on both the local and remote heads, and manually compare the output; this should tell you what exact files will be modified, added, or removed (including permissions!) by cutting at column 47.
The current code relies on enumerating files changed in particular (non-merge) revisions, under the simplifying assumption that the set of files effectively changed by an incoming bundle is equal to the union of those files changed in the non-merge changesets in that bundle. Of course this fails in various corner cases.