Audit uses of the screen buffer/alternate buffer, or come up with a design that makes this not an issue

[DHowett-MSFT]

Is this indicative of a larger problem? Should we file an outstanding work item to audit all sites of manipulating the active buffer and/or somehow change the design such that the methods cannot accidentally be called without resolving which one is the active one first?

For the latter, my proposal would be to hide all the verbage methods off the base class and implement some sort of interface that holds them that is only returned when/if someone has correctly queried for the active one first. I'd accept competing proposals, though.

Originally posted by @miniksa in #2729 (comment)

[DHowett-MSFT]

This would be a great place to discuss why the alt buffer is a sidecar to the current buffer instead of a new console buffer (which is a supported scenario.) If the alt buffer were a true top-level buffer (possibly with a link to its originating buffer), every API that look up the "current buffer" would get the right one.

[mdtauk]

What is the performance hit, if the command buffer was stored as strings, and re-drawn when needed - as opposed to being stored in texture memory?

[DHowett-MSFT]

Wha? It is. We don’t cache prerendered screen content.

[DHowett-MSFT]

This isn’t related to rendering :)

[mdtauk]

Ignore me then - I always think in UI lol