I've gotten rid of the "EVENT Extension"...instead moving WAIT into the libuv-based Network extension. This is because WAIT on PORT! is now only used for waiting for incoming network connections on a server (and waiting for a time, but you can use SLEEP from the TIME extension if you don't want your build to include libuv networking.)
While doing so, I converted the event loop inside that WAIT to use libuv timers...instead of the decades-old tangled multi-platform timing logic.
This means it's finally the case that the language core itself doesn't need the Reb_Device datatype, or functions like Register_Device() or OS_Poll_Devices().
And So, The Last Bit Of "Host-Kit" is Thus Gone!
...yet Ren-C is demonstrating itself doing more, on more platforms. What's the difference in approach?
R3-Alpha aimed to be closed-source, hardcoding the implementations of things like WAIT and READ and WRITE, as a fixed body of natives. These attempted to be extensible via the means of hookpoints that would be supplied as C code, with a grab-bag of structures and parameters to each function. This was supposed to avoid use of Rebol datatypes, with the concept that the functionality could be used as its own independent OS.
Ren-C basically throws that out the window. When you are packaging up a distribution of the language, you write your own natives...and any "extensibility" architectures are done through Rebol calls to those natives.
As an example: a fixed implementation of NOW is not based on a Rebol-defined "GetTime()" C API. There are various implementations of NOW... which actually is the Ren-C "get-time-API". If another extension wants the current time, it's supposed to use NOW to get it.
The implementations of READ of a URL vary so drastically between the WebAssembly build and the Desktop builds that URL reads are intercepted much earlier, and done via JavaScript fetch(). You really wouldn't want to convolute it so that network reads had to contort themselves in some way to fulfill an abstract C byte-level API. It calls "rebol functions" that are actually the JavaScript equivalent of a native.
Anyway, the desktop builds are still a lower priority than Wasm, but it's nice to see the last bit of hostkit cruft finally gone from the core.