selective commit not failing as documented

bzr 2.1.1 on Windows

According to 'bzr help commit' :

A selective commit may fail in some cases where the committed
tree would be invalid. Consider:

  bzr init foo
  mkdir foo/bar
  bzr add foo/bar
  bzr commit foo -m "committing foo"
  bzr mv foo/bar foo/baz
  mkdir foo/bar
  bzr add foo/bar
  bzr commit foo/bar -m "committing bar but not baz"

In the example above, the last commit will fail by design. This gives
the user the opportunity to decide whether they want to commit the
rename at the same time, separately first, or not at all. (As a general
rule, when in doubt, Bazaar has a policy of Doing the Safe Thing.)

But in fact, that sequence of commands executes without complaint and leaves branch 'foo' at revision 2 with both bar and baz.

Let's go further. The following sequence of commands also succeeds without complaint:

bzr init futbol
mkdir futbol\2010
bzr add futbol\2010
bzr commit futbol -m "commit futbol"
echo "furia" > futbol\2010\mexico.txt
bzr add futbol\2010\mexico.txt
bzr commit futbol -m "commit mexico.txt"
bzr mv futbol\2010 futbol\2014
mkdir futbol\2010
bzr add futbol\2010
bzr commit futbol\2010 -m "commit 2010 but not 2014" # says "added 2010" and "renamed 2010 to 2014"
# Those are names, not guids! So don't be fooled but ask: did the operations occur in the safe order?
bzr stat futbol # returns nothing, confirming that in fact both the move 2010=>2014 and the addition of 2010 both occurred

The end result is revision 3 with everything where you would expect: mexico.txt is in 2014 and 2010 is empty.

Is it possible that bzr was improved to do the "safe and right" thing but the help for 'bzr commit' was not updated?

If so, then the output of 'bzr commit' is potentially misleading. It sounds like the commits happened in the wrong order, but in fact everything worked right. Presumably, the potential for confusion arises from the fact that bzr prints human-readable filenames (which need not be unique) for old 2010 and new 2010 instead of the guids, which would be different of course.

I might recommend reordering the output of the commit command to show the true order of operations on guids. But that might create other kinds of confusion.