I think standardizing a file descriptor interface would be ideal. It's ridiculous that the file descriptors are exposed and densely packed. I wonder if a protocol could be made that demultiplexes for stderr and the new file descriptor could be made.
I'd like to make another standard file descriptor to manage the control plane, like stdin/stdout/stderr, but figuring out which file descriptor it should be is a bit complicated. I'm wondering if the OS could backwards-compatibly integrate it with stderr in the standard file descriptor at index 2.
Historically some systems did have more than three standard file descriptors - e.g. for MS-DOS C compilers, a de facto standard was stdprn was your printer and stdaux was a serial port - this was because while Unix by default starts each process with 3 inherited handles, MS-DOS has 5 (CP/M influence). NT-based Windows abandoned this
But trying to add a fourth now, would likely break too many things; some software will assume any fd > 2 is free for it to clobber.
The IBM mainframe operating system z/OS (formerly MVS), classically instead of numbers for inherited descriptors, the API uses names (DDNAMEs)-that would have made adding a new one a lot easier. But decades too late for that in Unix land, and eventually MVS added the Unix way too for Unix compatibility-the classic API still uses DDNAMEs, but many apps now use the file descriptor-based z/OS Unix API instead
