If you handle std{in,out,err} connectedness in other ways, I think you've covered 99.2% of the uses of hConnectTo. Neat idea borrowed from Korn & Vo's SFIO, but it hasn't proved to be all that useful.
I wasn't planning to handle connectedness at all. Is it important, do you think? (I'm not against the feature, just trying to avoid feeping creaturism...)
Yes, crucial I think - if stdout and stderr are connected to the same device, don't you want their output to be synchronised, e.g.,
main = putStr "foo" >> hPutStr stderr " bar"
should return "foo bar" on your TTY. Ditto for flushing stdout/stderr when peeking stdin.
You obtain the ordering properties by setting the handle to NoBuffering, otherwise you get buffered input/output. Wouldn't it be deviating from the report to do extra flushing in the buffered case? (this is something of a technicality, actually we already do non-report flushing in several cases and our line-buffered input isn't line-buffered at all). But I'm still not convinced we need to special case this. Cheers, Simon