I was just curious why the translation was thought to be important enough to put in that code
but now it is not in the new printf() for the Print class.
I'm pretty sure that was just a copy and paste from some other project.
That serial code is intended to process data 1 character at a time. The original version (while developing the USB code) didn't use interrupts at all. It doesn't matter if extra time is spent processing each character, since it's just going to busy loop on the UART, and it's never meant to be part of any real program anyway.
The print class code is meant to be in real applications. Performance matters. Processing data as a block is extremely beneficial when the output device is USB or Ethernet. Taking a block of data and processing 1-byte-at-a-time involves a pretty big performance hit if individual bytes are sent to the USB Serial write() function.
There are lots of ways to deal with this, of course, involving more complexity.
So to directly answer your question Bill, my motivation is based on performance and simplicity, and also somewhat laziness (far too many other higher priority software priorities), and also somewhat laziness in that the _write(fd, buf, len) API maps neatly onto the print class write(buf, len).
Then again, if not translating LF to CR+LF turns out to be a problem for a substantial number of users, I'll certainly respond by elevating the priority from "not likely to ever get around to it" to something likely to happen. Much like supporting printf() at all in the Print class, which has been on my low priority list for many months, I did get around to it, mainly because it's been requested more frequently. With only a limited number of hours in each day and a TODO list longer than I'll ever complete, I have to prioritize somehow. I mostly go with what the most people want, and adding yet another layer for LF translation (without a big performance penalty on USB) is no exception.