nicholas:

I see this in three parts:
- implement available kit/.so listing, similar to
in bin/kits but more generic (add to console
interface); this can be used to check -d options.
- implement available console/.so listing; same as
with -c, but for kits.
- modify -r in some way...not sure how exactly? (njs?)

I'd quite like server-options such as
--list-available-consoles,
--list-available-drawingkits
...and these should really work in-line with each
other. For example, if we have '-d GLDrawingKit
--list-available-consoles', then we'd only show
consoles supporting the GLDrawingKit. In a similar
way it'd be useful to be clearer when trying to
run with an unsupported combination that this is
not possible, eg. by doing the equivalent of
--list-available-consoles. Hmmm, maybe
--list-available-[consoles,drawingkits] should
just display the same output, ie. columnar listing
with |Console|Supported DKs|file-name/location|.`
[/braindump]

OK, what about:
--list-all-consoles (always outputs columnar as above)
--list-matching-consoles/drawingkits (checks -d/-c
options and outputs available ones)
--list-configuration-paths (for -r)

The alternative is to automatically update the
getopt strings according to which modules/paths
are present, ie. parse that before doing getopt.
While that avoids option-explosion, it means
parsing a lot of things even if you just want to
know the version ;)

Thoughts?