>> But your stream buffer is associated with 1 (singular) interface that
>> expects a definite encoding (that is not always utf-8),
> that's not even true because I can easily have a "tee" stream buffer that has two outputs, each with its own encoding (one writes to a file, the other to the terminal.)

No, the input to your tee is the singular interface. Your tee expects an input encoding, and if the outputs of your tee have 2 different encodings you have to transcode, and you need to put that somewhere, so you are going to need 2 buffers. This is a red herring, it doesn't address the issue, it just adds an extra layer. It at best reflects the poor design of the tee, which doesn't justify the design choice of having an intermediate encoding stream buffer, and why all other interfaces that don't do that should have to pay for it.


>> >If we designed std::cout today, we'd make it do exactly that. In
>> >`std::cout <<
>> x;`, the inserter (operator<<) would serialize `x` to a sequence of
>> characters in an encoding that can represent everything (i.e. UTF-8),
>> the stream would then pass that UTF-8 to the stream buffer, the stream
>> buffer would then transcode to the output encoding and write it out.
>>
>> But your stream buffer is associated with 1 (singular) interface that
>> expects a definite encoding (that is not always utf-8), why should the
>> data in that stream buffer be anything other than the encoding expected by that interface?
>> Why do we need to do that extra unnecessary conversion to an
>> intermediary encoding (that neither the input is written in or the
>> output understand), why not just do 1 transcoding that immediately achieves the goal?
>> Why do we need a process that tries to do more than what is necessary
>> just to have them do the wrong thing?

> Number of reasons. First, this is how wide streams have to operate, because they necessarily convert to wide in the inserter, and then convert to narrow in the stream buffer. Doing the same in the narrow streams makes the stream behavior consistent. (It is also how hypothetical charN_t-based streams would work.)

Isn't that just a poor design choice? Why does it have to do that?


> Second, it allows everything in the program to be independent of the output encoding, which is the only part that would vary at runtime. This makes it easier to get the program correct without testing it on every possible runtime encoding it's supposed to support. It's also a good separation of concerns because the inserters don't need to know what the output encoding is going to be.

Not having an intermediate encoding also allows everything in the program to be independent of the output encoding. These two things are not related.
Transferring data to the stream buffer is just half of the problem, the other half involves transcoding your stream buffer to the output encoding, which can happen before the data ends up in the stream buffer instead of before.

Are we talking about different things? I would understand "formatting" being done on a different encoding because you don't want to write 100 different formatters, but once formatting is done then it’s a different problem, you transcode that to the output encoding and that is what should end up in the stream buffer. I see no reason why it couldn't work this way.

Is it perhaps best to have a practical example? Should we diagram it to better understand what should happen where? Should we just make a repository and write down code emulating the systems we are dealing with and just walk it out? Where did we drop the ball? See where we should apply the fix?

I have one end of the rope, I know where it is and I know exactly what to do with it, I have the other end of the rope and I know exactly where it is and how to deal with, I know how to get from one end to the other, the problem seems to be all this stuff in the middle. This should be a solvable problem.