Before the patch, IDLE highlighted the \n endline with a red background,  which tk displays as red background from the blank space after the 4 to the right edge of the text widget, including in 3.8.8.

The 3.8 result, different from REPL, is due the the difference of using code._maybe_compile.  The latter catches the SyntaxError for "3 \\ 4", which has offset 5, recompiles "3 \\ 4\n", and raises the subsequent SyntaxError, which has offset 6.  (In this particular case where the message remains the same, the original SyntaxError instance with the original offset should have been kept and raised.)

I have occasionally made this typing mistake and found the long red line slightly annoying, but never thought to compare it to the REPL caret or report it as a bug.  The new parser made no difference in IDLE to newly annoy.

After the patch, the (1-based) offset stays 5, which IDLE knows means the 5th char and hence it now highlights the '4'.  Much better.  Thank you both for the report and fix.

Side question: https://docs.python.org/3/library/exceptions.html#SyntaxError says "Instances of this class have attributes filename, lineno, offset and text ...". Should it be documented that lineno and offset are both 1-based?  Are these CPython accidents or part of the language?  1-based line numbers can be expected as common across languages, tk and python included.  I believe that 1-based column offsets were viewed in a previous issue as a bug that we would not fix.