I'm moving ahead, quickly, with NULL isotopes.
Firstly I'll say that the analogy to atomic isotopes is an extremely apt one. So this isn't likely to just be a codename--it would be user-facing terminology: "isotope", "decay", "heavy null", "light null".
For background reading on precedent for names and notation, check out the Wikpiedia Article on Tritium. (I'm linking Tritium instead of Deuterium because it is radioactive, while Deuterium is stable.)
No matter what notation is chosen, I want the console to show which kind of NULL you have. If we want to help reinforce the "counting the number of nullons", maybe it's done with a number:
>> if false [<whatever>] ; null >> if true [null] ; null-2
More fanciful representations are possible:
>> if false [<whatever>] ; ¹null >> if true [null] ; ²null
But if there's going to be a function that generates these isotopes out of thin air, it should probably be easy to type:
>> null then [print "This won't print."] ; null >> null-2 then [print "This prints."] This prints. == ~void~
The canon property of the isotope is reactivity to THEN and ELSE, which suggests that rather than convoluted names for the tests (like null?/light) we can do better with that:
>> else? null == #[true] >> else? null-2 == #[false]
Grokking The "Gotcha" In The Mechanic
I want to point out what we're trading off here. We're making what seems to be 99% of cases easier to handle, while creating a small glitch in substitutability:
>> (x: if true [null]) else [print "As likely desired, this won't run."] ; null-2 >> x else [print "But going through variable substitution WILL run."] But going through variable substitution WILL run. == ~void~ >> x ; null <- here is why: WORD!-fetch decayed it, so no longer null-2
A little strange, but explainable. And when you compare to the headaches that voidification brought, this is a much more minor amount of pain to bear.
Notice that even in the first case, passing through assignment to a SET-WORD! didn't disrupt the value on the evaluator stack.
So... With That Laid Down... Naming?
I actually first wrote
NULL+ ... but quickly moved away from that, because that suggests charge, and we're deliberately talking about isotopes and not ions. The distinction is important, because the "superficial reactivity" is unchanged:
>> null? if true [null] == #[true] >> null? if false [<whatever>] == #[true]
So I thought maybe
NULL* to indicate some kind of...uncharged augmentation. @BlackATTR thought that looked kind of wildcard-y.
T-NULL could imply it is "THEN-reactive"
>> null-t then [print "causes then to run..."] causes then to run... == ~void~ >> t-null then [print "causes then to run..."] causes then to run... == ~void~
I actually am kind of drawn to the small leading decoration for the heavy null, with nothing on the "light" null:
>> if false [<whatever>] ; null >> if true [null] ; ²null
What I like there is the concept that it kind of fades out unless you need to pay attention to it.
I'm probably just going to go with NULL-2 for the moment, with the aforementioned ELSE? test to check if a value is a NULL-2.
"The essence of architecture is the suppression of information not necessary to the task at hand, and so it is somehow fitting that the very nature of architecture is such that it never presents its whole self to us but only a facet or two at a time."