The Troolean evaluates very oddly:
true && unknown ==> unknown
false && unknown ==> false
true || unknown ==> true
false || unknown ==> unknown
!unknown ==> unknown
It’s logical, but odd. This sounds like a communication nightmare. Seeing this in code is like seeing a ternary operator. It’s clever, but not nearly as readable as the alternatives.
Things like ternary operators were created in the 60s to hack the processing speed and memory requirements of compilers. It was adopted by C in the 70s. At the time, it actually made a difference in how fast the compiler processed the code. They no longer do have that effect. Compilers and interpreters are optimized way more than we can do when writing our code in high-level languages. Now, these things are just clever ways to reduce the number of lines of code for coding challenges or to frustrate the person who has to come after you and read your code. (In my experience that person is usually future you, who is not impressed with past you.)
As I’ve thought about this problem, I think that if this is for tracking quests for example, you should just create a Quest object, probably a Resource to track it. And under the hood store an int or use an Enum, but make it easy to see what it does so you can utilize it without ever having to look at the implementation code.
A new problem with overly clever Godot code these days is that if you post it here for help, and it’s full of things like weirdly used binaries, one-letter variable names, and overly-complex math, it looks like LLM-generated code. And the consensus seems to be for most users in this forum to just ignore posts that look like that.