Good points. Even with hg's mq, don't developers already need to handle tip moving underneath?
Yes, but that's the point of mq. If they have to commit the patches in mq in order to submit, then they have to rip them out and back into mq patches in order to revise, then repeat the process. It'd be insanely painful, which is why I say we really need to agree to move entirely away from mq, as bridging _that_ gap locally is not a reasonable workflow.
One of the reasons that I love git is 'rebase' (and I see that mercurial has its own variant of it). These days, I can't imagine doing development without it, particularly when dealing with projects where the tip/master branch is moving fast.
Yeah, but mq is less complicated than rebase, and more flexible/forgiving. The first time a non-power-user accidentally does a commit whilst in a rebase merge and has to reflog their way back to their code, I'd expect to hear some frustration. Since I really value contributions from those people, the text-patch-based approach of mq is simpler, safer, and more predictable for them. Maybe those people will be happy with guilt as a substitute (although I wasn't).
Like I say, I use git all day long for work and would like the benefits it brings for testing branches. However, I also spend time most weeks helping (or watching) professional developers work (or struggle) with git. I just want to make sure we don't lower the bar for git-preferring people and raise the bar for everyone else.
--Dan