Re: The guiding principle
We have enums for that; we define "this" as 0, "that" as 1, "the other" as 2, and lo-and-behold, if we decide we need a fourth value, we can add it to the enum. Just make sure you are using the same enum everywhere, not defining it multiple times, eh?
Nullable types have their uses too. A nullable bool can have values of true, false, and "fucked if I know". If you start relying on that third value to mean something specific other than unknown then you're in trouble. IMHO the closest to the correct implementation of a null value is in SQL, where a null value for a nulalble bool does not equal true, it does not equal false, and it also does not equal another null value. Languages where a null value is treated as false (JavaScript, I'm looking at you), or, even worse, as true, are just wrong.
The problems arise, of course, where one person uses null to mean "unknown", and another uses it to mean "not chosen", or "not defined" which are (subtly) semantically different.
In most cases, you will not be worried about the storage size of a boolean (or nullable boolean) vs the size of a machine word, so there really is no reason (usually) not to use an enum in any code that doesn't generate and consume that value straight away, where the purpose of that nullability should be apparent, because we all write well-crafted code, right?