That's an optimisation done by
When you type
screen. Because of the local echo and the
onlcr settings of the pseudo terminal device in the
screen window, the
\r\n sequence is sent to master side (to screen).
screen implements a terminal emulator where
\r is meant to bring the cursor to the beginning of the line and
\n to move the cursor down. To do that, where a terminal emulator like xterm would do X API calls to move the cursor to the beginning of the line,
screen has to send escape codes to the host terminals it is attached to to tell it/them to move the cursor to the left hand side of the screen window.
In case you've split the window vertically, that means send cursor positioning escape sequences to wherever the left hand side of the screen windows is. If not or if on the left hand side of the host terminal,
screen would just pass those
\n characters along so that the cursor be moved to the beginning of the line and one line down on the host terminal as well (since all terminals treat
\n the same in that instance).
echo runs and outputs a
\n character. Because of
onlcr again in the
screen window tty,
\r tells it to move to the beginning of the line, but the cursor is already at the beginning of the line, so no need to do anything which is why the host terminal doesn't receive a second
\r character. Then to move the cursor down because of the
\n it receives,
\n to the host terminal.
You can verify that by running in screen:
You'll notice that
screen only sends one
\r character to its host terminal.