"It's not something that can be solved one piece at a time. Pauan's prototype system makes it hard for a programmer to tell whether a given value is really a core 'table or just inherits from 'table, and that makes makes it hard to specify new behaviors that only apply to cases low on the inheritance hierarchy."
Even if we accept prototypes (which aren't necessary for message passing), that's not true. Data types could have a 'type message that would return it's low-level implementation, in the rare event that you actually needed it. Or they could have a 'proto message that would return what their prototype is.
Also, perhaps you are unaware of how prototypes work in JavaScript... it is quite easy to tell (once you know how) whether something is an Array, or simply inherits from Array [1] (it is pretty much never necessary to actually do this, though...) It is also possible to get completely fine-grained control, so you can extend all arrays, or a specific subset of arrays, or an individual array.
* [1] Object.prototype.toString.call(foo) will return "[object Array]" if and only if foo is an actual array. If it's a "subclass" of Array, then it will be "[object Object]" Clunky? Yes. But that has nothing to do with prototypes; it's clunky because prototypes in JavaScript suck. Prototypes can be done in a much more elegant way.
I think it should be `foo.constructor === Array`, but as I said, prototypes in JavaScript suck. That wouldn't be a problem in Arc.
