This can lead to additional problems. Say Fnurbification is a setting in code wrapped in an if block. Great, on or off is easy to follow. Now say the Disable Fnurbification is what is actually in code. Now, when someone has a problem with Fnurbification, you have to map state back and see that the inverse was coded for the IU and follow that down the stack. Don't even get me started on defaults. There is no good/easy answer here.
There is an easy answer: "Disable Fnurbification" is not what should be in the code. Present the right interface to the user, and fix the code when practical. Presenting something backwards to the user only makes it harder to fix later.
I deal with hundreds of these types of selectors from some inherited code. When a disable changes 2 lines of code to wrap functionality in an if block v adding many scattered if blocks to accommodate the enable case, I'll probably go with the low code solution. If I can easily accommodate enables then sure but it's just not always that easy.
