Apologies if this explanation is confusing. I've mentally internalized the problem here, but I'm not sure if I can fully articulate. Here goes...

When receiving characters in a stream fashion (in either conhost or the Terminal), there are a bunch of situations that occur that run off the golden path rails of "just put this into the buffer and move the cursor forward by one".

A few major categories of these are:

1. C0 control characters (tab, backspace, newline, carriage return, etc.)
2. Surrogate pairs for UTF-16 (two wchar_ts are required to form one U+ codepoint)
3. An entire run of characters required to figure out a particular cell display or run of cells.

We need to solve 1 and 2 first. Solving 3 will probably require a bit more interaction with the CustomTextLayout in the DirectWrite renderer to perform some sort of read-ahead or multiple-pass calculation over text as it flows in stream-wise to figure out the columns it should take.

The existing manifests of this sort of work are WriteCharsLegacy in the console host (which is a thousand line or more monstrosity full of multi-pass switch cases, loops, and gotos) and the stream write thing in TerminalControl (I think, might be TerminalConnection) which @zadjii-msft affectionately warned against it becoming "WriteCharsLegacy2ElectricBoogaloo" in one of his comments.

I think what needs to be done here is:

1. Create a third entry point to the buffer object that accepts text in a stream write fashion, potentially "buffering" before it inserts into the buffer for reals (or has the ability to look-behind at what was just written) taking over the duties of the "WriteCharsLegacy" type methods into the buffer itself so at least 1 and 2 can be handled in a unified-ish manner.
2. Teach the buffer and/or let the buffer accept some sort of loose pfn that will connect it up to the text layout engine and let it query for column counts or glyph run information as stream characters show up and adjust the behavior of their neighboring glyphs.