Based on the code @bdw429s posted, it isn’t clear in which order those intercepters run, so it isn’t clear which setting would take precedence (which I think is the heart of what @adamcameron was asking?), so this seems like an error-prone way to have the settings.
Just as the "disabled": false setting was unnatural, so too is having multiple Boolean settings that are not really independent.
Having something like "serverIdentity": "boxlang" (or "lucee" or "adobe") would be more natural and less error-prone.
I don’t think a setting - especially a boolean one - should only work based on special magic rules dictated opaquely and elsewhere.
If I set a boolean setting to be on (so: true). I expect it to be ON. Not “on unless some other setting at the same level of the settings hierarchy(*) is also set to [some specific value]”.
(*) eg: it would be legit to have a subsection of settings be controlled by a master “on/off”, and then if on, subsettings then come into place. That makes sense and is intuitive. This is not the case here.
I did a new stable releaes 1.1 due to a few issues to conform to beta 3.
Also, I changed the settings to what Sean suggested. It made clearer sense. Plus added validation behind the scenes as well.
engine : "adobe" or "lucee"
Internally, we still switch the boolean bits, as those are easier and faster to use. However, you now must set the engine. By default it is set to lucee