I've been considering using ssyntax in parameter lists to set apart special behavior in parameter lists, with destructuring being the normal behavior. (I was inspired by aw and someone else using (def foo (string:x) ...) syntax for coercing parameters, but I can't find that thread....)
Anyway, here's one of the takes on optional arguments I've been pondering:
(a b c .o opt1 nil opt2 3)
This is pretty similar to the Common Lisp approach, and you can even use &optional instead of .o for added similarity. :-p The main advantage in my mind is that it's less of an abstraction leak; Arc doesn't really support argument lists of the form ((o a) b), so a function with optional arguments has only one extra conceptual boundary in its argument list, and you should only have to punctuate it there.
For a more customizable approach (especially if you do want ((o a) b) to work after all), I added a backtracking pattern matching library to Lathe a while back (http://arclanguage.org/item?id=11956) just for the purpose of making destructuring more customizable. I didn't end up doing anything with it after that, but if and when I did, parameter lists would probably look like this:
(pfn (a b c (.o opt1) (.o opt2 3))
...)
The parameter list here would be wrapped up as '(struct (a b c (.o opt1) (.o opt2 3))) and compiled via the library to determine the variables it binds and what code it uses to bind them. In particular, the library would identify the 'struct operator as a "patmac," and it would use that patmac's implementation like a macro to determine what the rest of the expression meant. In the process, the expressions '(atom a), '(atom b), '(atom c), '(o opt1), and '(o opt2 3)--without the dots--would be sent off to another library that implemented a "list-patmac" system for monadic parsing of sequences.
As I mentioned, I never got this far. The second library doesn't exist at this point, and I haven't added even one patmac since I finished the proof of concept and made that post. It's not like it would be hard to get to this point in the design, but I've just been focusing on niftier things. ^_^;
So there you go, one straightforward syntax and one general-purpose syntax. The ultimate elegance struggle, eh? :-p