The behavior isn't exactly "wrong" . But it caused considerable confusion for quite a while.
The Output.print* functions wrap around to the top of the screen rather than scrolling, and they don't clear the line when they're starting to output to it.
This combination made some debugging logging in a random number generator look like it was printing out values for var ints that were in excess of 65536 (it was actually printing shorter stuff into a longer line and what was left at the end was a few additional digits, which then looked like they were part of the line).
The solution was to make sure there were spaces at the end of the logging output -- not even necessarily enough to clear the line, just enough to make clear the boundary between what was output this time and any previous leftover garbage.
Scrolling is, I think, impractical as things are currently implemented. Clearing the line, though, that isn't obviously crazy. Or just emphasizing in the documentation that it behaves this way, and suggest making sure you can tell where your latest output ends and thus detect what is leftover garbage at the end of the line? I dunno, nobody ever finds and reads the documentation.
Scrolling is, I think, impractical as things are currently implemented.
Scrolling is not only an option, it's even suggested as a possible implementation in the book. The default implementation is without scrolling, which makes the other one even more satisfying, when you implement it yourself.