I think this is too much cognitive load on people who likely don't ever need the functionality. The most important principle should typically be "don't overwhelm the user who is following the default path" followed by "don't put extra burden on developers unless it is really justified and someone would be willing to pay for it".

Most of these options are truly obscure, added for some very specific problem in a hurry. They are documented if people want them, having a UI in front is worse than starting from the documentation for unsupported features - it kind of is instead giving people enough rope to hang themselves with. If they all have to be supported instead, that's an unreasonable developer burden that nobody is going to pay for.

That makes sense. Perhaps a compromise is a dedicated tutorial page which lists off the available values and a short description of what they are (if we don't already have that... I think we do).

It's in the Codebook. It could be split out if you think important. Probably makes sense too actually, given the list has grown.

I can do that. I'll give the documentation a review and think this through, then close this and create a new issue for pulling the values out into another document.

I think the documentation itself is fine but perhaps we need a test for this... scan for all uses of get_value / set_value in the code and make sure they are referenced on that doc page (with ability to add exclusions by regex pattern or exact match).

__specsettings_documented_test_set already does this.

__specsettings_documented*