Here's a playground snippet writing to os.Stdin:

https://play.golang.org/p/KRsTZeUNDrx

It reports an error on the playground:

write /dev/stdin: Bad file number

But works without error on macOS and Linux:

hello
<nil>

I'm horrified that this restriction wasn't always in place. If we want to give it a try for 1.14, I assume we want to do that the sooner the better, to catch any regressions during the freeze and betas.

This is nothing specific to Go and just standard system behaviour, right? It's not the Go runtime that is opening these file descriptors and we have no idea what programs might use them for. It's the same thing as programs calling seek on stdout. Distasteful for a general purpose program but not necessarily wrong (e.g. if you control the parent and the child processes).

Even ignoring the compatibility implications of changing this long-standing behaviour, I think it's a bad idea to start messing with the FDs inherited from the parent process in this way. It just results in a system that is opaque and hard to understand. Certainly too much magic for my taste.

We don't open these descriptors. We don't have any support in the os package for "this file is only available for read access even though the descriptor is writable." So this is more like a feature request than a bug fix.