As no further info is provided, closing.

Another good test would be: to boot into another system (say Debian or Gentoo) and then chroot into the Slackware system.  If the problem does not occur then, it shows that there is nothing wrong with nano and ncurses, but that somehow the Slackware kernel has an issue.  Maybe the upstream kernel code has a bug and the way that Slackware configures and/or compiles it exposes the bug.  Or maybe Slackware miscompile or misconfigures the kernel.

You're still not providing a reproduction recipe.  The phrase "just adding a few lines of unique letters and/or numbers to the bottom until all lines were filled, and then saved" is way too vague.

You have to describe exactly and in all detail what you are doing -- all the keystrokes.  Preferably you don't type the extra text but read in a second file that you prepared beforehand, so that it is easy to each time add the exact same piece of text, to see whether you get the exact same result.  Lines being "saved in the wrong order" sounds like an impossibility -- if you typed them in a certain order, they will be saved in that same order even if the display is messed up.

And no, chrooting is not okay.  The kernel versions may be the same, they were compiled by different distros, and thus will be different.  To reproduce the problem on another system, you actually have to boot the other system.

Chrooting is not a good way to try and reproduce the problem: you are actually using the kernel (and thus the console-driver code) from your base Slackware system.  To really try and reproduce the issue on other systems, you need to boot into them.

You say that you can reproduce the garbling issue in multiple situations, but you're not exactly describing the steps for reproduction.  For me to be able to reproduce the issue, I need a detailed and precise recipe.

On nano 7.2, I noticed similar/worse problems when I chrooted into Fedora, Gentoo, openSUSE (using defaults on all, and no ~/.nanorc) but not when chrooted in Debian-/Ubuntu-based.
        On some of those and Slackware, if you edit a full screen and are at the bottom, and save, sometimes there ends up being an unnumbered line between two numbered lines, and sometimes the last couple lines are saved in reverse order.
        The worse thing is when you do that, sometimes the first line of menus will be displayed above part of the text file, and part of the text file under that on a line or maybe at the beginning of a line of menus, all garbled.
        I tested on large plaintext /etc/*.conf files just adding a few lines of a letter and/or number to the bottom (so I don't think these were unicode).
        Seems something went wrong with calculations for where the cursor is, maybe, and where things should be displayed.
        Apart from booting some of those GNU/Linux distributions later, and FreeBSD later this Summer, is there anything else I can test so far?  It's probably best to see if a few other people can test this.

One thing to watch out for when trying to reproduce the issue: maybe it only happens when using nano after having used another program first, one which leaves the terminal in a subtly strange state.

Do you maybe use a `tabs` command in your ~/.bashrc or ~/.profile or some other init file?

It would be great if you could test your editing also on the console of two other distros.  If you can't reproduce the problem there, then it's something in Slackware.  If you can reproduce it there, then we have a problem.  But it will also mean that you know more or less how to reproduce the problem, and can tell me how.

Looking at your /etc/nanorc, I see you have enabled both sets of interface colors ('set titlecolor ...' et cetera).  The second set overrides the first, so you could delete that first set.  Also, you include all nanorc files and then three of them explicitly.  Those latter includes are redundant.

With "tab size" I wasn't referring to nano's 'tabsize' option but to the tab size of the terminal.  I know ncurses can make use of tabs to move the cursor efficiently over a short range, and also that it can be told not to do that, but this is just a vague memory and I don't actually know how it works.

Please post the output of `env | grep -e TAB -e TERM`.

(There is a preview button, but it's somewhat hard to notice -- either at the top of the input field, or to its left.)

I had a typographical error; the stty size is 134 480.

Sorry, the description of your problem is too vague.  What I understand is that something goes wrong when you edit on Linux console (a VT, 'tty' reports /dev/ttyn), but it works fine on any terminal emulator ('tty' reports /dev/pts/n), right?

• How large is your Linux console ('stty size')?
• Do you use softwrapping?
• What other options do you use?  Please attach your ~/.nanorc file.
• Have you looked at your file with another ncurses-based program (like 'less') to see if it displays right?
• Do you have non-ASCII characters in your files?
• What version of nano?
• What distro?
• Anything strange in your environment variables?
• Have you tried using --linenumbers (to maybe get an early warning when something is displayed wrong)?

My suspicion is that either your VT reports a different size than what the console actually has, which will mess up the cursor movements of ncurses because it relies on certain behavior near the edges; or the tab size is not what ncurses expects, which will also mess up the cursor movements (but much worse).