I had a small change sitting in a branch for about a month and wanted to update. I didn't want to do a merge. I did find that someone had created a simple rebase plugin for bzr, though. That made things a lot easier.
I tend to commit lots of incremental progress. I talked to a couple of bzr users who do the same. They insisted that it was important to their project to include these changes that definitely don't compile (e.g. "committing because I'm getting up to go to the bathroom"), etc... in the long-term history of the project because it can help them remember what they were thinking when they were writing the code.
Personally, I do the similar, but I rebase -i before I push and squash and reorder most of that down into small, working chunks that most accurately reflect the real changes to the project.
That is, it's a higher priority to me to say what happened than how it happened. I'm thoroughly uninterested in what the state of the codebase was when you came up with the idea to work on something, how many times you pulled upstream code down, how many times you went to the bathroom, etc... I just want to know when your change went in that affected the state of the project, and exactly what it did.
Theoretically, a recursive merge message would tell me this. In practice, it does not, and the merge diffs don't necessarily show the change that affected the tree, but the delta that had to be applied to resolve conflicts on the merge.
I used to be a gnu arch user, and as such, I used to find it of utmost important to record every minor file save in my permanent history. I've learned since then that it doesn't help me actually understand the project.
Also, the use of sequence numbers (hg has the same problem) causes a lot of confusion. Humans seem to like the idea that there's an easy to understand sequence, but that's false on any project with more than one developer.
Specifically I had this problem with "buildbot try" -- the default implementation does a working-tree diff against the same revno upstream (e.g. if "bzr version-info" says 571, then it uses "bzr diff" to create a patch and sends it upstream against 571). However, if I've committed locally (because...that's just the right thing to do), then it will find either than upstream doesn't have a 572, or it's a different 572. Enter "bzr revision-info -rsubmit:" which introduces network (took 7.49 seconds for me just now) and "bzr diff -rrevid:[long-string-i-can't-double-click].."
I can't tell you all of the exact scenarios that were causing me confusion, but they came down to things like the above.