Options. They're great fun.
I ended up creating a hash of groups of hashes of options, with each option having a hash of attributes.
Grouping meant I could address them in groups, for passing to the RSS or Google APIs, for arranging in a usage report, whatever.
Having a distinct name means I can refer to them by something in the options hash of values (post GetOptions), and the attributes allow me to set defaults (if desired), mark them as mandatory, and specify their getopt suffix (e.g. start =i).
So I end up with a 34 line data structure of options. Ten lines then process that into 3 variables - one to hold the values (default and post GetOptions), one to pass to GetOptions as option specifiers and the last to note which options are required.
The problem: I'm using pod2usage (erm: Pod::Usage). However I suspect I'm going to have to do something funky if I want to be able to dynamically generate a usage report from the options and have them in the POD. Hmm. Or I could have another program postprocess google2rss making the POD into something reflecting the structure. After all - one shouldn't be afraid of programs that write programs.
If anyone has any ideas or module references, please feel free to mention them. Literate programming has a lot to answer for (or at least it would if it were more popular and people actually used it rather than having things like POD which is most decisively not LP). I like the idea of programmatically generated POD reflecting a data structure, but calculating it on-the-fly seems to be an intriguing concept.