I don't think you read my post closely enough.
Don mentioned some of this, but I'll add some additional comments.
The seemingly strange ordering of characters/lines on a 4x20 display is not something that the libraries have intentionally or unintentionally done in their s/w or was just an "oversight".
See Don's LCD addressing link to see how the hd44780 memory is mapped to various lcd geometries.
Believe me many people know about the inconvenience the h/w memory addressing creates for certain usage cases for the end user. And this issue comes up about once a month or so.
To make the display work like a mini terminal takes additional library s/w and in the early days of Arduino, realistically, there was not enough to spare code and ram space for that code.
Even today on the AVR platform, the m328 is still quite limited on resources and other smaller chips like the tiny series are much smaller and some of the LiquidCrystal type libraries are being used on those processors as well.
There are many tradeoffs involved. For example, should it require the ability to read LCD display RAM?
That would make the code smaller and eliminate the need for a shadow RAM in the library but not all implementations have that capability. i.e. devices that use shift registers can't do reads and for pin implementations, users may not have a spare pin to control the r/w pin and some i2c based hd44780 type displays don't have the ability to read from the device.
It could also be done using internal LCD memory offets to "scroll" the display without having to re-write any of the display. However, MANY arduino users are using home() to set the the cursor position to 0,0 but the current implementation of home() in the libraries uses a hd44780 command that also undoes some other internal hd44780 settings.
That could be changed, but then it may break other existing code that works because of the way the home() works today.
Also there has be a way to enable/disable this capability since it can and will break other s/w written to use the existing hd44780 modes like, right to left mode, custom font characters, or horizontal panning.
There are a few libraries (2 that I know of) that did add support for this type of "terminal mode".
I've used & tested both, and both have some issues and some things broke (didn’t' work correctly) with some of my test code.
Like I said before, it isn't as easy as one would think to add the s/w to make the hd44780 LCD work like mini terminal, especially if you want it to "just work" correctly across many devices and at the same time not break other existing code that uses other hd44780 capabilities or that is very resource limited/constrained.
At some point I'll be adding support for a "terminal mode" capability to my hd44780 library, which means it will exist on top of many different communication interfaces like pins, shift registers, i2c, etc... and will work for all the geometries, but I haven't yet figured out how to best to do that.
I may do it with a wrapper class so that users that don't want/need the capability or don't have the extra room in their parts for it, don't have it consuming any resources in their build.
A wrapper class implementation also has the potential to work on any existing library vs just with my hd44780 library.
But even a wrapper class comes with some issues as it can potentially break other libraries that use wrapper classes like PrintEx to seamlessly extend Print class libraries like LiquidCrystal type libraries to add printf() support.
It is a difficult problem to solve so that it creates a "it just works" type of solution given all the devices and environments involved.