Carl proposed: > The other path that seems reasonable to me would be to use the same > naming scheme as for the block types, i.e. reserve all-upper and > all-lower forms (and die if an unrecognized one of this form is > encountered), and let the custom ones live in the namespace of > mixed-case identifiers. That sounds sane to me as well; the only > question is whether that much structure is needed for config options.
I did not consider this issue when designing S26, but in considering it now, I think Carl's suggestion is entirely sensible and in line with what I intended. Specifically, I think it would be easiest to be consistent and say that all purely lowercase and all purely uppercase config option names are reserved, and that unrecognized reserved config options generate at least a warning when they are parsed. Mixed-case config options should be freely available to users and the parser should simply accept them without complaint and include them in the internal data structure it builds, whereupon they will be available to user-defined Pod extensions. Damian
