The principle for the previous behavior, prior to this ticket, was, by analogy that "Rename Christopher Tubbs to Michael" was intuitive enough, and that one shouldn't have to say "Rename Christopher Tubbs to Michael Tubbs". Likewise, the first parameter could be fully-qualified, because it needed enough information to identify the table to change, and the second parameter was simply the new name to give the identified table (not a new location/namespace... simply a new name).
I feel it's non-intuitive that a rename doesn't just update the name of the table, but might also move it. By expecting unqualified names, it's clear that this behavior is not possible, but we also allowed fully-qualified names, as long as it was referring to the same namespace, so users weren't surprised if they always used fully-qualified names.
So, I'm not convinced this was any more intuitive than the documented behavior, but I'm not strongly tied to either one, as far as intuitive-ness. However, it was made quite clear in the javadoc how it was expected to work, and the previous implementation followed the documented behavior. It now no longer does. If this change is acceptable, then it needs a corresponding javadoc update.