Most unixy programs actually do have them divided. stdin, stdout (and a third for stderr). It would be very easy to separate the streams to different places.
ETA at the last place I worked, we actually had the touchscreen on one desk and the program running in a window on another computer. It was pretty nice to type something and make it show up across the room.
On this topic of stdin, stdout - wouldn't it be neat if - instead of signals - there was an input channel called stdctrl that you could send control messages in on.
Glad to read about the scenario at your last place - I've never seen this in action.
Well those are just the defaults, a program can open a lot more sockets if it wants to. IPC is an old problem with a lot of pretty good solutions by now.
Well, it's not exactly what you describe (which does sound kind of intriguing), but Linux does offer the signalfd(2) syscall, which allows you to read signals from a file descriptor. Doesn't do much for the sender of said signals, however.
At AOL circa 2000, our application framework had a Tcl interpreter listening on a "control port", so that you could telnet to any app and get stats, change settings, etc.
Of course, nowadays that's more commonly done with REST endpoints, which I think would satisfy your stdctrl idea.
ETA at the last place I worked, we actually had the touchscreen on one desk and the program running in a window on another computer. It was pretty nice to type something and make it show up across the room.