Brainstorming designs for data (lag) visualisation in TAStudio

After last week's lengthy discussion of just what lag means, really, we're still not clear on that point.
But what is clear is that IsLagFrame is holding us back. It's clearly not good enough and no-one likes it or can even agree on how to use it, but it's also integral to emulation and recording.
So since we'll have to live with IsLagFrame for the foreseeable future, I thought we could make some progress by thinking about the user experience of a hypothetical piano roll. (On Discord, I got the impression that the other devs considered UX more important than my concept of "correctness", and I have to admit that it is.)

As always, it was brought up that we have (at least) 2 concepts called 'lag', that a TASer might only find 1 useful, and that which one is more useful depends mostly on the console.
From the previous conversation we had the idea of colouring individual cells red or green, or using a colour in-between red and green for some rows. This lead us to quantify the problem as needing to represent > 1 bit of information but all we have is a bool, obviously just 1 bit.
This lead me to ask: what kinds of things could TAStudio do if it had, say, 2 bits' worth per frame? And so I quickly made a note of how 4 states could be represented with colours and promptly forgot about it for a week.

Concept Y1: As we're used to, background is green when inputs are polled, and red otherwise. When the virtual system "lags", an icon is shown in the gutter beside that row.

Concept Y2: The background now indicates "lag" per se (changing from the base white to red). The stroke colour of the frame index is red when inputs are not polled, and black otherwise.

See also #1741 and https://tasvideos.org/Forum/Topics/26848.

Start with the TAStudio lag discussion in this issue, then read #1741 and the linked TASVideos forum topic. Compare the Y1 and Y2 mockups and clarify which lag concepts and frame states must be represented. Done would require an agreed UX direction before implementation can be scoped.