One of the principal ideas of the null state is to be a falsey state a variable can hold that reflects it hasn't been assigned... but that you can access without getting an error on word fetch.
Increasingly I've come to believe that functions should not accept NULL states as arguments, unless they are specifically designed for doing conditional tests (e.g. IF needs to take NULL in its condition slot...)
I think that if you write code that says if not text? var [...] and VAR was null, that should be an error to cue you into the fact that your test was meaningless. We now have empty splice that can serve a role of a "friendlier" form of nothing (the new BLANK now that _ is SPACE). So you can use that for your variable if you need tests like this to succeed.
If you really want to "opt out" and get the test to fail on null, there's OPT which will pass a void... and then that will let you say "I meant to do that". (And I think OPT of the ~()~ antiform should probably also return a void state, but you wouldn't have to do that to get the test to fail if using the empty splice as your blank state).
Should Testing Quoted Values Soft Fail?
I kind of feel like you're potentially missing some of the picture if you're working with quoted values and don't realize it:
>> foo: first ['<thing>]
== '<thing>
>> tag? foo
== ~null~ ; anti
I mean, it is a tag... it's just a quoted one. Same with pinned/lifted/tied values.
>> bar: @<thing>
== @<thing>
>> tag? bar
== ~null~ ; anti
These could give ERROR! back, and you could say try tag? bar if you wanted to say "yeah I know it's quoted, and I want that to not be a match".
(I've discussed leading colon as a shorthand for TRY in the modern world, so it could be :tag? bar in that world, for people who like brevity.)
I don't think having a speedbump here is as likely to be as inconvenient as one might think. And it could cue you to ask tag? noquote bar or tag? plain bar or whatever your particular meaning was.
I'm not as confident about this as I am about the need to panic (not error) on null.
What To Call The Typeset?
I think the set of things that we're talking about the signature testing for here is "every stable value state except for KEYWORD! and TRASH!"
I've struggled with the SOMETHING? term and the over-generality of NOTHING?... and here I think we don't want ~okay~ to pass either ... and ~okay~ seems like something.
TESTABLE? 
TYPECHECKABLE?
Well, I'll have to think about it. In any case, I'm sure enough that I want to start failing on NULL.