Currently settings can be controlled by:
 * Config files (mostly static files, plus overrides from hwdetect.js)
 * Command-line arguments
 * JS commands (via the console or the GUI)

These all provide different subsets of functionality, and different names for the same features. That's kind of silly, and they should all be unified. Often I want to set an autostart map in a config file (because that's less painful than editing the command line in the VS IDE), or change graphics settings on the command line (to quickly compare performance in different modes), or make the pathfinder debug overlay be enabled by default instead of clicking GUI buttons, etc.

Some settings allow players to cheat (e.g. enabling the pathfinder debug overlay, or disabling graphical features like FOW). It'd be good if we could easily identify these cheaty settings, and discourage their use in proper multiplayer games.

Graphics settings are the most complex area. Take shadows as an example: (the precise technical details aren't really important, just the general complexity)
 * Shadows can be "disabled", "shadow map" or "blob" [hypothetically - blob shadows aren't implemented yet].
 * Shadow maps can have "PCF enabled" (better quality) or "PCF disabled" (faster on some hardware).
 * If the shader-type setting is "ARB" (not "GLSL"), shadow maps can use "SHADOW2D" or "2D" mode.
 * Shadow maps can be "with unused colour buffer" (wastes memory) or "without colour buffer".
 * Shadow maps can have any power-of-two square texture size (512x512, 1024x1024, etc).
 * If the render-path setting is "fixed", then "shadow map" is not available.
 * Unless the graphics drivers are OpenGL with certain extensions, or OpenGL ES, then "shadow map" is not available.
 * "SHADOW2D" is only available if the graphics drivers support some GL extension.
 * Some drivers/hardware are slow and should have shadows disabled by default for acceptable performance.
 * Some drivers/hardware require "with unused colour buffer", otherwise they'll either give detectable errors or (if I remember correctly) silently break.
 * The graphics drivers impose an upper limit on shadow map texture size.
 * Users should be able to choose a tradeoff between quality and performance.
 * Users shouldn't be able to choose options that break the game.
 * Developers should be able to test every combination to find optimal performance and find driver bugs.

So there's a load of options, which often depend on other options, and often depend on drivers/hardware. How would we implement this in a usable GUI for users, and in a cleanly-implementable UI (probably config files, not GUI) for developers?

I suppose a usable GUI could be radio buttons (or equivalently a drop-down list) like:
[code]
  Shadows: ( ) Off                    [means "disabled"]
           ( ) Very low               [means "blob"]
           ( ) Low                    [means "shadow map", 1024x1024]
           (*) Normal - recommended   [means "shadow map", 2048x2048]
           ( ) High                   [means "shadow map", 4096x4096]
           ( ) Ultra                  [means "shadow map", 8192x8192]
  Shadow filtering:
           ( ) Off                    [means "PCF disabled"]
           (*) On - recommended       [means "PCF enabled"]
[/code]
The "[means ...]" aren't part of the UI, they're just for this explanation. The "recommended" labels come from our hwdetect.js (effectively a database of optimal configurations for various devices), and will be the default until the user overrides them. Any options that aren't supported by the hardware would be greyed out. If "shadows" is set to "off"/"very low", then the whole "shadow filtering" section would be greyed out or hidden. If the currently-selected option is not supported (e.g. you copy your config file to a less-capable machine), then the UI would still show your old selection (greyed out), but the engine would automatically fall back to some other similar supported configuration.