@iArnold Solving AI and cryptographic protocols of the future? It's a pretty long list for that 1.0 release. I'm amazed they find the time what with the 64-bit support, multithreading, file I/O, and bootstrap...

Well I seem to have made a little bit of progress on the asynchronous error front. While there is definitely a limit to how much time I want to spend mucking with the R3-Alpha device and port code, there's something to be said for having such a large sprawling bunch of "stuff" to use as a backdrop for thinking about cool Rebol and API applications.

@hostilefork wrote: There is something called an AWAIT handler, which is essentially a callback on a PORT! to tell you about events that have happened. I don't want to get too deep into the R3-Alpha port model, but something has always bugged me about the naming of the events you get back when a particular asynchronous READ or WRITE has happened. That'…

Hrmph. So as with COPY/PART, Rebol does truly treat /PART as a "suggestion". This means you always have to check if you care.

At the moment the "match dialect" (used by MATCH and ENSURE and friends) given an INTEGER! checks the length. So you can say ensure text! second [<a> "b"] or ensure 2 [<a> "b"]. That could help casual cases of this.

Yet another reason interpreting (a)/b/c as a PATH! and not (a) /b /c is important: the API, because when you are splicing you can say rebValue("(", obj, ")/b/c"). The interpretation of rebValue(obj, "/b/c") is by necessity different--commas separate items.