The following snippet behaves differently in the C IO implementation than in the Python IO implementation:

  import sys
  sys.stdout.write('unicode ')
  sys.stdout.buffer.write(b'bytes ')

To test this, I have created two scripts, testpyio.py (using _pyio) and testio.py (using _io).  The output is as follows:

% python3 testpyio.py
unicode bytes
% python3 testio.py
bytes unicode
%

In my opinion, the behavior exhibited by _pyio is more correct.  It appears that to get the C implementation to print the lines in the correct order, there must be a flush in between the statements.  This extra flush would create a lot of overhead.

I am attaching the two test scripts.

The C implementation prints the output in the correct order if each write ends with a newline.

This is by design, for performance the C TextIOWrapper stores the encoded strings in a list, and calls buffer.write() less often.
You may try to add
   stdout._CHUNK_SIZE = 1
and get the _pyio behavior.

This seems like a common need (particularly for stdout and stderr), and setting `stdout._CHUNK_SIZE = 1` is relying on an implementation detail.

1) Can the documentation for TextIOWrapper be updated to clearly describe this extra buffering (how often buffer.write is called, etc.)?

2) Can there be a flush-like method, say write_to_buffer() to force a buffer.write() without the overhead of a flush?

I agree this deserves documentation. I'm not convinced it's a common need, though. Usually you either use stdin/stdout in binary mode or in text mode, but you don't interleave both quite frequently.

I would imagine that this would come up in most programs that read data from a pipe or from a socket (which are binary data) and then output to stdout or stderr.  I ran across the problem in my first non-trivial port to Python 3, and it seems like a common case to me.

But having the weird behavior documented is the most important thing.