Main screen comparison highlighting disagreees with current line

Not a bug. Just a distinction between HOW the two displays go about presenting the data.

In the over/under single-line display, bytes are compared in a strictly POSITIONAL method (think arrays of chars where only the two chars in position "N" are ever compared). But in the MAIN display, it is sequential RUNS of chars that are compared (subject to specific suppression categories that mostly deal with optional White Space variations).

They INTENTIONALLY do not show the same results (although its not impossible); its simply two ways of looking at the same data. Your given data case is representative of a fixed size "field" where perhaps each char signifies something unique (not unlike a row of switches).
This kind of display is incapable of properly depicting INSERTIONS of indeterminate length, which is what the main window INLINE display is better equipped to render. This introduces a "sequential aspect" to what gets highlighted. I could say its why both exist, but the simple truth is that the single line display dates from the early days of the tool, while the INLINE variant came much later when the poor presentation of insertions made itself evident.

At times, one display will be better at showing "what makes sense" than the other based entirely on the specific data in question, hence we keep both.

With regard to the single line display being EMPTY at startup, that is perhaps because the user has not yet DESIGNATED which line is considered to be "current" (via picking with the mouse, or requesting some particular hunk to be displayed). Specifically it watches for which line holds the character cursor (assuming your display settings are adequately set to make that visible). As there are TWO (Left/Right) windows, the "current" line is whichever window received the most recent interaction to a specific line.