It's probably useful to gather some resources on places to look for comparison/contrast/inspiration for I/O designs. So post here if you have them. I'll list a few:
Boost.ASIO
The C++ world has a powerful offering of Boost.ASIO, which stands for "Asynchronous I/O".
The focus is to link up various "easily leaky" C-style things into the C++ world, where things can be wired together more robustly. Of course, to take advantage of that, one must be able to read source that looks like these examples:
https://www.boost.org/doc/libs/1_63_0/doc/html/boost_asio/examples.html
...which aren't necessarily all that complex when you boil down the syntax. But I haven't really used it. I feel like sitting down with it might be educational for me, and perhaps how they've broken down the problem could have easier-to-read parallels. One might even imagine using C++ in the implementation, at least for starters, if it demonstrated benefit.
Node.JS
JavaScript is single-threaded, Node.JS was sort of rapidly put together, and people seem to have been hacking up Node.JS programs fine. As far as I recall, Node didn't try to attack every kind of I/O through some kind of uniform interface. You just have objects that you pass callbacks to when they got the information you requested. Here's a description of how to do file I/O:
It raises the question of how wise it is to try and pipe everything through one kind of READ and WRITE, vs clip: make clipboard! ... then clip/read, where the parameterization and data return types can all be customized by that object.
0MQ
I don't know a ton about 0MQ, but when I think about the idea of what some kind of unified-futuristic-I/O-model might do for someone, it's the kind of idea that comes up. What if PORT! always spat out blobs of Rebol values?
One scenario I think is interesting to model is two Rebol apps on a network, where one is able to send Rebol-styled data at a certain rate, and the other end can receive it and process it with PARSE. What might that look like?
Uniserve
I've never used Uniserve:
https://www.softinnov.org/rebol/uniserve.shtml
But supposedly it was a driving factor in creating Red. Yet Red lacks I/O.
It was created to address a perceived deficiency in Rebol2. Did it? Was it in competition with R3-Alpha ports? Does anyone who's used it have good things to say about it, bad?