Some Good News On This...
...the basic concepts in virtual binding that power RebindableSyntax should be able to provide the hooking I have sought, whereby a construct like IF or CASE can defer to a concept of conditional testing that comes from its calling environment.
The default notion that would drive the mezzanine and such will be that only antiform NULL is "falsey". But you could redefine this for your script, or even at the granularity of what is useful within a certain function.
The technique has been shown to work, and it just needs to get grafted into more natives (and the name for the function chosen). I have some reasons why I'd like this function to be called CONDITIONAL or COND, and return either a VETO definitional error or VOID (vs. ~null~ or ~okay~)...but that's an explanation for another post.
I don't know that being able to override this will turn out to be as useful as you might think. But my hope here has always been to let everyone have their own way within their customization environment. I seek to align the foundations in order to make a system whose internals mechanically work across an infinite number of arbitrary programs. But after that, there's no rule that the definitions used for any given script have to "work" for any more or less than the particular problem it is tackling.
(But the more general the problem and generic your script or library is, the more likely you'll want to be using the default choices...they were picked for a reason.)
Some More News That I Think Is Very Good...
I think that underscore needs to be the lexical form for the space character.
_ would thus not be BLANK! as a distinct type, but SPACE? (as a type constraint of the RUNE! fused issue!/char! type).
This won't opt out of enumerations in the way I was envisioning BLANK! might, which makes it not fit for some intents of nothingness.
But an empty splice antiform... ~()~ is available as NONE, which can be a sort of "new blank" 
Unlike VOID, an empty splice can be stored in (non-meta) variables, and fetched via ordinary word access:
>> var: blank
== \~()~\ ; antiform (splice!) "none"
>> append [a b c] var
== [a b c]
>> append "abc" var
== "abc"
An empty splice will always be "found" in a series, while a VOID never will. So you might think of none as a kind of "positive nothingness", while void is "negative nothingness"
>> find "abc" ()
== \~null~\ ; antiform
>> find "abc" none
== "abc"
If we added NONE to the things that DEFAULT was willing to overwrite, it could do a decent job of being variable-assignable-nothingness that still was legal to fetch and wouldn't give errors when using in series operations the way a null would.
(I'm not totally sure if this is a good idea, but it seems to be.)
I'm hoping you'll be finding that you were mistaken, the design has just the right number... even though it's far more when you add it all up, including TRASH (antiform issue), QUASAR (quasi issue), QUASI-BLANK (quasi empty splice), QUASI-NULL (quasi word)... packs and splices, the whole lot.
Everything is related through a coherent system, and comes together beautifully...
