I've now taken the next big step in terms of implementation, in changing over the networking TLS code to use libuv. That covers listening sockets for servers, as well as streaming data for reading and writing.
There's no new asynchronousness, but the custom/buggy/bad ways based on "devices" are gone...as well as my custom/buggy/bad temporary replacement to help migrate to libuv.
So it's one of those things where if this step goes well, you shouldn't be able to tell a difference. (It's fortunate that I'd written some stress tests for the httpd server, because that catches a lot of issues.)
We're Still Using Usermode HTTP/TLS Code
An interesting thing about libuv is that it doesn't have any built in TLS integration:
SSL support · Issue #1128 · libuv/libuv · GitHub
This means our usermode TLS code--built on the cryptographic primitives of mbedTLS--is actually a kind of interesting option.
The TLS code itself is sort of coherent in terms of being an "executable spec". If the dialects used continue to converge with the RFC, it might have the bones to become one of the most understandable codebases for TLS there is. Maybe. 
But I say "interesting" option (as opposed to "practical") because we should remember that the usermode TLS is slow, incomplete, on the fringe of being maintained at all, and known to be insecure. As I've mentioned previously, it extracts certificates and decrypts the data without actually verifying against a certificate authority. A so-called man-in-the-middle attack could be done by someone who impersonated the other side of the connection. It's not exactly zero security...your average person watching wireshark packets go by wouldn't be able to read plaintext passwords go by.
Still...it's a bit of a novelty people might find thought-provoking, that could grow into something better in the future. And my point is that there's no free lunch with libuv and TLS. If we weren't using the usermode Rebol TLS, then we'd have to use the higher-level facilities in mbedTLS that take care of that (right now we only build in the lower-level cryptography that the usermode TLS uses).
Big Questions About The Event Loop Loom
The networking code is the first case of using the libuv callbacks and delegating to the libuv event loop. So it's a much bigger deal than the synchronous filesystem API substitutions.
Right now the only time we call the event loop is in WAIT, and it's still using some ad hoc timer logic instead of libuv timers. As I say--it's a first step. It's a long way to the point where you could have an interactive chat program feeding lines at the unix prompt coming from the internet while you're idle at the keyboard.
Regardless of the specifics...I'm proposing a grand vision of scrapping the existing attempts at asynchronousness to replace with green threads and "channels", as in Go. Event dispatch would be very different in that world...and libuv might not even be the best choice. Maybe everything should just be rewritten in Go. 
Ignoring all that for now... at least we're building on a platform abstraction layer that other people develop, maintain, and document. That fights much more than half the battle in the event that you decide you want to pick another platform abstraction layer.
Anyway I just wanted to give an update that libuv networking is in. Report anything broken, at least that wasn't already broken before...