Eli Zaretskii wrote:

>> Because we now have a simpler solution.
> 
> I don't think it's simpler: it causes 'message' write to a different
> file descriptor, and thus introduces a backward incompatibility.

I meant simpler to implement and easier to maintain. My email discussed the 
backward compatbility issue, which is negligible.

>> Emacs uses stdout reasonably extensively for this sort of thing already; see
>> 'write_stdout' and I can cite several other examples.
> 
> write_stdout is used in exactly 10 places, which I wouldn't call "extensive".

As I mentioned, write_stdout isn't the only place stdout is used for this sort 
of thing. Another example is w32con_write_glyphs. I'm not saying stdout is used 
as often as stderr; however, stdout is used in a reasonably large set of places, 
and nobody cares. In this sense, Emacs differs from typical Unix-like utilities.

> It is used where AFAIU any other file descriptor would
> be problematic.

In the places where write_stdout is used, stderr is no more problematic than 
stdout is. Neither is guaranteed to be displayed to the user.

> I don't understand how could you make these assertions.  What are they
> based on?

You're asking me to prove a negative? OK, I concede; I can't do that. However, 
my statements were based on experience in using Emacs and in reading its source 
code and bug reports and complaints about it.
> So I think your previous proposal for message_to_stderr and vmessage
> should be okay to go in.  But not the rest, sorry.

OK, I put that proposal into master (with some minor improvements). Also, I 
installed the attached patches to fix the most-annoying remaining stderr 
interleaving problems without changing stderr buffering. This should be enough 
to address the interleaving problems on GNU/Linux, in areas where the OS lets us 
address them.

Unfortunately, GNU Emacs master still suffers from interleaving problems on 
Solaris, AIX, and perhaps some other POSIXish platforms, because their fprintf 
implementations write "%s"-formatted strings separately. Although it's easy to 
fix that, no fix is likely to meet your standards.