Hmm... if we can make qpush/qpop safe to use even with local changes,
then the --force flag would not be needed :-)

It would be nice if MQ would look ahead and see if the patch conflicts
with local changes (not just on a file basis, but on a hunk-basis).
But I don't think it's mandatory since it is a --force option, and
users should not use --force if they don't know what they are doing.

Ok, the important part here is "when I know that my changes do not overlap". mq
should know it for you, because when you mistake you highly risk to lose local
changes *plus if panicking a little, mangle changes in the current patch*.

What I propose is: --force is OK if local changes files do not intersect with
patched files, fails otherwise.

Yeah, I agree with dduvall -- I use qpush/qpop -f all the time when I know that
my changes do not overlap. The current behavior is exactly what I would expect
of a -f option.

For what it's worth, this behavior is useful.  You can have the changes in your
working directory, realize they need to be applied to a patch that's not at the
top of your queue, pop your way down to the patch, refresh the patch, and push
your way back up.  (That's for pop -f, which exhibits the same behavior; it's
useful for push, too, if there's another change in your wd that you don't want
to refresh into a patch yet through that process.)  I've been using this
recently, and was happy to discover that it worked.  I don't care so much if I'd
need to throw another option into the mix, but I like having it.

$ hg init t
$ cd t
$ echo a > a
$ hg ci -Am t
adding a
$ echo b >> a
$ hg qnew -f changea
$ hg qpop
Patch queue now empty
$ echo c >> a
$ hg st
M a
$ hg qpush -f
applying changea
Now at: changea
$ cat a
a
b
c
$ hg st