> Both now write to stdout when stderr is unavailble
> 
> tested with stderr closed (in a terminal emulator,) and a TTY, also in a read only
> directory.

DESCRIPTION
     The nohup command allows the specified utility to be protected from
     termination if the user should become logged out (for example, due to a
     modem line or TCP/IP connection being dropped).  To do this, nohup sets
     the SIGHUP signal(3) ("terminal line hangup") to be ignored, then
     executes utility along with any arguments.

     If the standard output is a terminal, the standard output is appended to
     the file nohup.out in the current directory.  If standard error is a
     terminal, it is directed to the same place as the standard output.

     If the output file nohup.out cannot be created in the current directory,
     nohup attempts to create the file in the user's home directory.  If the
     file nohup.out cannot be created, either in the current directory or the
     user's home directory, nohup will exit without invoking utility, with an
     exit value as described below.

my reading is that your test scenario quite plausibly should result in
the output being discarded, because you've created a situation that
matches none of the conditions where nohub manul page says it would show
or store the output.  then it would do the default.

you can also refer to a more minimal standard describing nohup behaviour at

    https://pubs.opengroup.org/onlinepubs/009695399/utilities/nohup.html

anything beyond that spec, is heading into defacto incompatible
behaviours chosen decades ago by "families" of code, and the last thing
we want is newer sub-families in the ecosystem.

As a general rule, extending behaviours must be done with great care
because even minor changes can have unexpectedly great impact on real
life programs.

not calling you Jia Tan, but your mail is weak on making your case.  it's
worse -- you don't even try to show that it is important.  why is it not
important enough for you to show where it is important?