+1. The consequences of merging patches with real changesets accidentally are
sufficiently bad that I don't think Hg should let you do it casually.

MQ rebase is already opaque enough; I don't see it being any worse with the need
to specify --force in one step.

Current workaround for Unix users:

[hooks]
prechangegroup.mq-no-pull = ! hg qtop > /dev/null 2>&1

The usage message for qclone says "If source is remote, this command can not check if 
patches are applied in source."  But it is possible to interrogate a remote repo to 
figure out if MQ patches are applied, e.g. checking the output of "hg id -r qtip 
default" in the usual case.

So it seems a useful feature for both qclone and pull to refuse to pull MQ patches, 
with the option to override.

Maybe I misunderstood the OP. My comment applies to when the _source_
repo of the pull has mq patches applied. If we're talking about the
_target_ repo and forbidding update in it, then please make sure that
the mq rebase process still works (qsave, update, qpush -m).

Like pmezard says, I think it would be fine if pull was allowed, but update
should probably not be allowed. Not sure what that means for qclone.

This would likely break qclone. If so, then please don't. We should at
most disallow pulling the mq changesets, but not those before qbase.

pull --update may be disallowed, pull itself has no interaction with the working
directory so no direct influence of mq. What you want to avoid is updating to
some rev while you have MQ patches applied, or worse, merge with the queue.

Pull is allowed when mq patches are applied, but that seems to be a good way to 
make a mess of things.  Should be disallowed by default.  Maybe '--force' to 
overide?