I've wondered aloud in the past if Rebol truly needs a LOGIC! datatype. One line of argumentation might say that TRUE and FALSE are really just a limited sense of an enumerated type, which could easily be expanded. (To a tribool, even, with an 'indeterminate' state that fails both tests for truth -and- falsehood...)
So if people are always going to be trying to get back to the WORD!s true and false (or on or off, yes or no, etc.) for output purposes, are we doing them any favors by having LOGIC! in the system as its own narrow type? Doesn't it just delay the inevitable?
Perhaps NULL and BLANK! could be the only falsey types:
>> 1 = 2
== _
>> 1 = 1
== [] ; ...arbitrary truthy thing?
Or the devil's advocate might ask if the rule against "reserved words" be broken, and just take true and false away from WORD!? e.g.
>> type of first [true]
== @logic! ; see new datatype proposal post for why this would be @logic!
I've never thought this to be a good idea. So the nominal proposal has just been to make LOGIC! literals something like $true and $false.
I'm now convinced LOGIC! false as distinct from BLANK! is critical
The evolution of NULL over time has seen it come up as being nearly equivalent in meaning to BLANK!. You see this in the variants of DELIMIT (e.g. SPACED, used by PRINT):
>> var: try if false ["opted out by variable"]
== _
>> spaced [if false ["opted out directly"] "stuff" var]
== "stuff"
BLANK!s give you a means of not triggering an error when accessing a variable. But the behavior is often supposed to be the same in a dialect as a NULL that didn't go through a variable. The same is true in PARSE:
>> norule: _
>> parse "aaaccc" [norule some "a" :(if false '[some "b"]) some "c"]
== "" ; e.g. success
And PARSE is a good example of a dialect where I feel the result of a logical operation should be how we drive rules to fail. This just seems to make sense for the meaning of LOGIC!, and is incredibly clean:
>> mode: 'alpha
>> parse "aaa?bbb" [
some [
:(mode = 'alpha) "a"
|
:(mode = 'beta) "b"
|
"?" (mode: 'beta)
|
(fail "This is a much better use of the FAIL term!")
]
]
== ""
What I mean to say is that the result of a comparison operation feels like it needs a different semantic weight than something that opted out or went missing. A distinct type is called for here. Doing something weird like calling out one special @-style-word as falsey (e.g. @false) feels like bad mojo for accomplishing it.
Why not stick with #[true] and #[false] ?
I really don't want to be getting the WORD!-look confused with the LOGIC!-type.
rebol2>> type? 1 = 1
== true ; This is very anti-educational
So the way I see it, you're going to be seeing these LOGIC! literals in a true LOAD-able form a lot.
We've discussed in the past being cutesy and not using words at all, like #[+] and #[-]. Or some variant of :-) and :-( , and now that we have the full range of UTF-8 codepoints we have some emoji options I would suppose: 
and 
.
"Nonsense" aside...having the brackets around seems visually too heavy for something that will be coming up often that has such an atomic nature. $true and $false aren't stellar, but they're at least decent. But maybe #[true] and #[false] should be left as is. I dunno. This needs a pinned down answer, and the rendering needs to be able to LOAD back a LOGIC! and not get you a WORD!.
Anyway, my main point here is just about the idea that the LOGIC! type and literals of it seem of foundational importance...and that the BLANK! notion is truly no substitute any longer for falseness (as I once might have mused it could be).