@jasnell So, there are a couple issues with your API proposal.

The biggest is that actually creating TTY streams isn't particularly supported:

In normal circumstances, process.stdout will be the only tty.WriteStream instance ever created (and only when isatty(1) is true).

In fact, I've tried to make tty streams before and found it's virtually impossible. You can only make one if the fd is a tty and it is not already in use, which is basically never. I actually don't know of a case when you could ever make one manually without severe hackery.

However, exposing a setBlocking method publicly also causes some concerns:

1. The existing problem that stdio streams do not have consistent APIs depending on the stream type is yet again amplified (very difficult to fix)
2. It doesn't work for pipes, but putting this functionality into net.Socket publicly is harmful because of TCP connections.
3. I'm not sure unblocking is ever valuable for this, in any manor that isn't strictly theoretical.
   • Same goes for pipes, where blocking only has theoretical niceties.

describes the default behavior of tty.ReadStream

I doubt that is useful due to the above, or the correct place to put it, since no-one will go looking for the TTY module from console.log() or process.std{in|out|err}.

I will add a note to where the existing note is for file piping though: https://nodejs.org/dist/latest-v6.x/docs/api/process.html#process_process_stderr