It also looks like you're trying to use Andrew Koenig's Fundamental Theorem of Software Engineering: "Any software engineering problem can be solved by adding a level of indirection." One thing I've always wondered about that is whether you can, by adding a level of indirection, solve the problem of having extremely poor performance as a result of having too many levels of indirection. It actually looks like that's what you're after, though: "XPLC itself won't have anything in it related to remoting, but I intend on having a framework to support remoting available separately...." So instead of either forcing the users of the system to have to deal with a system that's too simple to meet their needs (forced local/GDI), or too difficult/bloated to be workable (forced into CORBA), you let them choose which of several approaches they prefer. I like it...
I wonder if you can somehow use that same approach for your other "controversial" design decisions: Not including exceptions nor supporting threads (if I read right).
One thing that concerns me is that the abstractions will leak. In other words, designing everything now to assume a local address space must necessarily break when remote objects are added into the mix--if object remoting is a goal, it turns out that "you needed it" all along, and bolting on a framework later won't do the job. (I don't know XP well enough to know how the other practices balance YAGNI out, so this might be something you've already accounted for.)
Thanksgiving: At the relative last minute, I decided to go visit Mom & friends for Thanksgiving. I managed to get a decent rate on a flight leaving Thursday morning and coming back Saturday evening.
In an excessively circumloquatious E-mail to an old friend of mine and to a recent girl-space-friend of mine at church, I referred to the holiday as corporate exercises in communal gratitudinous communiqués. I had fun later explaining what that, and the rest of that whole E-mail, actually meant.