All of this is related. XPLC lacks object remoting, so making remote objects available locally in a transparent way is not possible, because XPLC lacks the indirection needed. So the problem of remote objects is left unsolved, but in exchange, I didn't add too many levels of indirection, so performance is still good.
Exceptions would require an indirection, as would "supporting" threads. XPLC supports threads, in the sense that it is going to be threadsafe (altough it isn't at the moment, it is accounted for in the design and will be added later), but it will not cover up for thread unsafe components like COM does (with its apartments and proxying), because that would require an indirection and lots of complexity.
You liked the fact that I let people choose, but unfortunately, to do these things transparently, you need to have hooks that would need to be in more indirection. I don't think you could add exceptions, because really, exceptions are just a more transparent version of return values (in fact, exceptions in COM/DCOM are in HRESULT return values). So you can't really add exceptions in an optional package.
My plan for remoting is to use messages rather than direct method invocations. When you use a direct method call in XPLC, you can rest assured that the method call overhead is O(1). Remote objects will have to be accessed through a separate message queue mechanism, which is how the abstraction doesn't leak: when you see a message being queued, if it takes a full second to reach its destination, the direct method call promise was not broken.
Of course, if the promise that message queue does is looser than the one for direct method calls, nothing prevents me from having very fast message dispatchs in the same address space. It's just that I drew a line between methods and messages.
I suppose you could support thread unsafe components by putting them in their own thread and using them through messages, but it won't be transparent (you have to use messages rather than direct calls, but this is good, because really, the single threaded component might be busy, which would delay the call, so it doesn't fit the O(1) promise of direct method calls).
So basically, I'm "taking the difference seriously" (section 7 of the note). About that note, I'd mention that I disagree with its last section, "middle ground", where it says that objects in another process on the same host could be acceptable. I think this is just as worse (the other process could segfault, the equivalent of a remote machine going down) without much of the advantages. I say they are accessed through messages too, and then you can pick between in-process, in-process but in another thread, in another process or on another host completely, without restriction.