Your suggested "primary design decisions" seem to concern exclusively syntax & reserved names for built-in operators. This is a very specific and very superfluous aspect, for the latter two are the thin outer skin of any programming language.
From what I have read, Arc goes much deeper in its design principles. Those can be enveloped as the thorough "bottom-upness" of design: both read & write access to the language, right through to its primitive elements.
And this is the direct result of Mr. Graham's popular relation of Arc's design philosophy (http://paulgraham.com/design.html): a programming language ought to strive to accomodate those who themselves are qualified to design languages, translators and compilers, among other things.
This is at the foundation of Lisp, and Arc is a promising language because its designers seem to have well understood that foundation.
What is left to add, though, are modern counterparts of those 1960-s innovations that made Lisp superior not only in principle, but in reality also.
Not that this is necessarily a bad thing - it's good to take your time thinking about hard problems. I just hope the Arc community doesn't get too pissed off with pg's slow pacing that they go off and create yet another could-have-been-great-but-for-x-y-and-z new lisp dialect.
newLISP's default dynamical scoping fits very neatly among its other daring innovations (and, let me remark, such are wholly in the spirit of Lisp.)
One of those is the notion of a "context". Apart from neatly giving provision for all your lexical scoping needs, it adds the freedom of choice between argument passing by-value (which is default - another idiosyncratic bold feature of newLISP) and by-reference (through contexts). And - again, in line with Lisp's more traditional superiorities - contexts are first-class objects in newLISP.
My initial proposal here was not that newLISP is anyhow better than Arc. It cannot be, for Arc may eventually turn out to be anything; and, after all, this is an Arc forum.
It was, rather, that we should all go and use newLISP, to help Arc's developers learn from an existing complete powerful Lisp that has brought into practice many new design ideas.
Ah, but of course dynamic scoping is bad for any, any language, whatever the design goals. Everybody knows that since ages ago. <end of my turn to be clever>
My fascination about newLISP was exactly that: "What?! Dynamic scope by default?! ...Oh, but look, they say you can scope lexically & do closures with no fuss... Context as an explicit first-class object? hey, that's an idea, for once."
newLISP indeed has real flaws, - which can be mistaken for mistakes, unless you take into account the exotic design requirement for newLISP: to fit a Swiss-army-knife function library, together with functional and O-O programming support & a stand-alone web server, into a 300kb executable.
We can but guess of the author's intent. My guess is that the built-in distributed computing functionality has something to do with the plan.
