support assisting the decision about where an uncommitted change should be committed

Another example which is somewhat less "trivial".

A user has been struck with inspiration and gone on a bug fixing spree, and now needs a way to separate out their changes into a more logical set of patches.
At this point they have a fairly involved set of changes in the WT which are being split up while switching between threads.
While in the process of deciding what changes go where, they sometimes do a test switch, to see if this change would fit best in that thread.
If that ends up in a conflict,
  A) they probably don't want it in that thread after all, and
  B) they can't switch to another thread because they now have conflicts that have to be resolved.

having a way to avoid the switch if it would conflict allows them to poke around a bit to find where things fit best, without going through a time-consuming conflict resolution process before they get to jump again.

For me, this situation typically arises if the user is carrying several changes around with him in the WT as he switches threads. Eventually, a WT change may conflict with a thread that the user switched to, even if the user has no intention to commit that particular change on that particular thread. However, now, in order to restore mobility to his loom, the user must resolve the conflict.

For instance, suppose I have three threads:

C
B
A

Now, suppose I make some changes while my current thread is B, but then I realize that some of those changes should be committed in A, some in B, and some in C. I will probably `bzr commit' the changes that belong in B, and then do `bzr down-thread' to commit the changes I want in A. But what if the changes destined for C conflict with A? If I had known ahead of time that this was the case, I might switch to C to commit those changes first, or I might shelve the changes for C, commit changes in A, switch to C, and then unshelve the changes for C.

The primary distinction between this issue and that covered by bug #227339 is that, here, the conflict is between the WT and previously committed revisions in the thread being switched to, whereas #227339 deals with pending merges as a result of moving up the loom after committing to a lower thread.

So, there are several things to tease apart here:
 - how do you commit changes to a different branch/thread
 - what is the primary use for switch
 - whats the best default.

I'll support a --require-clean mode on switch or something, to say 'dont switch if there are conflicts', but defaulting to that seems really weird - pull itself can conflict when a directory is deleted and there are pyc files left behind; forcing switch to break when that happens would just annoy me :)