Just a naming convention, but it is such an insanely easy convention to follow and recognize that what could be an absolute nightmare (dynamic binding outside the lexical scope being unwittingly shadowed and broken by an innocent choice of variable name) simply never happens. Almost like magic. :)
I see you have corrected the above by switching to a different name (a reasonable way to go) but it might be fun to see if you can stick with one and expand differently based on whether one or more than one value is supplied (meaning of course you need to support what we call &rest in CL in the parameter list of twodimlist. What I do not know is how well Arc likes to expand a macro into code referencing the same macro.
Maybe arc could also provide online code upgrades as well.
I like the idea of qualified names (namespaces for things) but prefer it to be divorced from the name of the resource where you find it. For example, in Perl and ruby I can require 'coolstrings.rb' which doesn't have anything to do with a "coolstrings" namespace or class but does change the way strings behave. It also provides a way to elegantly implement pragmas.
Live code upgrades is a great feature. Lisps already support this to some degree. If you make an app and expose a REPL on some local port then you can recompile functions on the fly. I'm not sure how it handles the current execution stack when this happens though.