Other than select software being pissy about it, not much. Just like how there's nothing wrong with CRLF, except for select software being pissy about that too.

I do like concatenating files with cat, and if a file has its final line not ending in newline symbol the result is ugly.

I know it's just me but my worldview is that the world would be better if all editors had "insert final newline" behavior

My problem is that what I input (and observe!) doesn't match what's persisted. Worse still, editors lie about it to me until I close the file and reopen it. And just to really turn the knife, various programs will then throw a fit that a character that I did not input and my editor lies about not being present, is present. I hope it's appreciable why I find this frustrating.

I expect my editor to do what I say, not secretly(!) guess what I might have wanted, or will potentially want sometime in the future. Having to insert a newline while concatenating files is a chore, but a predictable annoyance. Having to hunt for mystery bytes, maybe less so.

I have been using and programming Unix systems for almost 30 years and have not run into anything like what you are describing.

What Unix program "throws a fit" when encountering a perfectly normal newline in the last line in a file?

"Unix programs" I haven't ran into throwing a fit per se. That's why I didn't write that.

What I ran into issues with was contemporary software that's shipped to Linux, such as Neo4j, which expects its license files to have no newline at the end of the file, and will actively refuse to start otherwise.

I have a feeling I'll now experience the "well that's that software's problem then" part of this debate. Just like how software not being able to handle CRLF / CR-only / LF-only, is always the problem - instead of text files being a joke, and platforms assuming things about them being the problem.

Wait, are they're no editors that don't lie to you?

Yep. Select software being Unix command line tools.

It makes writing parsers more complicated in certain cases because you can't tell without lookahead if a newline character should be treated as a newline or an eof.

What? Which crazy non-binary format makes a distinction between CRLF(EOF) and just (EOF)? Apart from a plain text file, that is.

I won't mention telnet because you don't use it, but in CSV and similar data it is quite a trouble to normalize the data. So instead of 2 possibilities now we 3 to detect.

I don't get the CSV part. You can emit a new row after a line ending and on EOF with non-empty buffer. What's the tricky part or third option here? The crlf is never a part of the data.

I have never had any issues with this using a standards compliant CSV parser.

Absolutely correct: You never had issues. Other people have built other software that does not use modern CSV libraries. They work just fine today and don't need to update, wouldn't even be possible for most cases in either case.

Please do consider that many software products will not change and they will still be actively used on production environments that you will never have interest about.

Well, GP proposed removing the idea of trailing newlines from standard *nix tools entirely, so I think it's fair to ask what shop is going to update their RHEL deployment to upgrade to a version of `cat` or `sed` that doesn't have trailing newlines but can't spend 5 minutes to handle a newline properly in their CSV parser? That doesn't make a lot of sense.

And it was pretty clear from the context of norir's comment that they were not talking about legacy software, they were talking about writing new projects/file formats that used newlines as a separator. Just because you want to shoehorn your legacy projects into this discussion doesn't mean that they fit.