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 (thing) -> ~null~ antiform
(thing) and null -> ~null~ antiform
(thing) and (thing) -> ~okay~ antiform
Today's rule is that THING is any non-null, non-void thing. VOID causes an error.
Including VOID Would Be More Flexible. Worth It?
void and void -> ~void~ antiform
void and null -> ~null~ antiform
null and void -> ~null~ antiform
void and (thing) -> ~okay~ antiform
(thing) and void -> ~okay~ antiform
The VOID*VOID=VOID would give you 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. 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.