When I look at something like try tag? bar the only thing that jumps out to me of why the question would fail would be if BAR was a function that generated an ERROR!, and you tried to test the error's type.
I wrote about that here:
Typecheck and ERROR! ... pass through vs. :RELAX ?
You kind of only get one axis of "thing to definitional error about"; it shouldn't mean too many things. And that's the meaning I'd likely lean toward.
Where this runs into trouble is not in the equality test itself, but in things that use equality in their implementation. Let's say SWITCH, for example.
var: null
switch opt var [
^void [print "You'd do your equality matching on voids"]
]
You might be able to get away with writing that as:
switch opt var [
() [print "Voids might match Voids for EQUAL? purposes"]
]
Maybe that would work but it feels unclear if you thought you were testing against nulls. You could reify it:
switch reify var [
'~null~ [print "You'd do your equality matching on voids"]
]
I guess it just pushes too far away from being able to write:
switch var [
none [print "You could do this in historical Rebol"]
]
That says what it means and means what it says. So I don't think we can really drift too far away from that without making things unclear. The safety isn't worth it.
But I Do, So Far, Like Not Accepting NULL? in the type checks.
In my experience this just doesn't tend to mean what you think it means:
value: null
if not tag? value [...]
It's usually a bug, and I don't mind needing to write if not tag? opt value [...] -- it has caught real problems.
But it would be nice if there were some way to set this as a policy, e.g. on a per module (or per-function?) basis? Just don't know quite how to do it, as RebindableSyntax has some tools for this but they break down past one layer of calling a library function.