Well you know Rebol PORT! was crap
There's obviously a wider context for this statement with that discussion, however there's something I'm not clear of in your (@hostilefork's) port! critique:
for sure the TCP scheme is flawed—you've found plenty of work in evaluating HTTPD alone
It's likely the file scheme will have similar glaring flaws if the tires are kicked sufficiently
I don't know too much about the serial port scheme/extension (is it even a scheme?)
stderrorwere dropped for implementation expediency in the move from Rebol 2 (though there was no
We have a few other higher-level schemes with various degrees of love and care
Does your overall 'crap' verdict extend to the PORT! datatype concept and structure itself (language quirks pertaining to naming—per aforementioned event names—notwithstanding)?
I've built a few schemes for Rebol 2 and 3 over time and I do tend to like the concept of these malleable interfaces with their tight association with the core verbs and the url!/file! types (it's possible I'm biased given my own investment in that way of thinking).
I do believe scheme authoring could benefit from much more transparency and documentation—there's still a degree of mystery as to the specific mechanics (particularly when building schemes on top of the TCP scheme). In general though I see ports/schemes as being in that small set of Rebol's core and compelling distinguishing features.
My confusion may just come down to the terminology used (ports/schemes/specific schemes), but I'm open to the prospect that my own perspective is misguided and that perhaps ports are an attempt at oversimplification of complex systems.
*that small set being something like: data representation, evaluation model, parse/dialecting, size/self-containment (Tiny Elvis) and ports/schemes. Would also add 'embedability' based on your own efforts in honing the API and the Amish constraint on the source.