I think there are two distinct cases here. The first is when a procedure is taking a number of options/switches. The second is when the function has a long list of optional arguments.
I actually think the second is pretty rare, especially if the argument list is ordered by practical use. The first is handled pretty nicely by passing in association lists or hash tables. Of course, the current syntax for creating hash tables doesn't make using them as arguments super-easy, but they're the equivalent of passing a dictionary in python for kwargs, and they don't require any new syntax.
edit:
In my imagined world, your last example would look something like
I don't see the distinction between taking a number of options and having a number of optional arguments. To me, this is exactly the same. A switch is an argument that is only checked for true/false, which means that in ordinary function calls you only really want to bother with it when passing 't.
It's true that passing a data structure can do most of the job of keyword arguments. Any searchable structure will do, really. Perhaps the simplest form from the call site's point of view is a property list. If Scheme's plist-get was implemented in Arc (trivial, but pg would probably pick a shorter name):
(def foo (a b c . rest)
(plist-get rest 'g))
arc> (foo 1 2 3 'g 42)
42
So, what do keyword arguments give you that tables/alists/plists do not?
1) better self documentation - the function signature tells what keys it understands
2) less code in the function body - you access the value like any other argument
3) a default form which is only evaluated if no value was given - without adding code to the function body
