Ren-C has infix AND and OR, which are conditional--not bitwise. Since #[true] and #[false] no longer exist, they now act on things being "branch triggers" or not...which is basically "non-null things vs. null".
So we have for instance:
null and null -> ~null~ antiform
null and (truthy) -> ~null~ antiform
(truthy) and null -> ~null~ antiform
(truthy) and (truthy) -> ~okay~ antiform
Today's rule is that to get TRUTHY to be truthy you need some non-null, non-void/trash thing. VOID and TRASH cause errors.
Including VOID Would Be More Flexible. Worth It?
void and void -> ~[]~ antiform
void and null -> ~null~ antiform
null and void -> ~null~ antiform
void and (truthy) -> ~okay~ antiform
(truthy) and void -> ~okay~ antiform
You'd get an error if you tried if (void-thing) and (void-thing) [...], which seems good to me.
It's strictly more powerful. Going along with the general idea that "Errors aren't big enablers of creativity", I am leaning toward endorsing it.
Particularly because accidental creation of VOID has been pruned further than ever. It's not something you can ever pick out of blocks or get from a variable. And with type checking there'll be even more confidence that those who are doing this are doing it intentionally.
It's not a priority. But I can see how it could be useful.