Should END-able constructs all use ^META parameters?

:face_with_head_bandage:

Due to LIFT the UNIVERSE, ^META arguments no longer leave room in the "unlifted" band for special states to indicate <end> or "unspecialized". Because all variables are stored "lifted", and "unlifted" when fetched. The point of distinction is merely whether a FRAME! gets them automatically decayed before the lift.

So the only way to go any "lower" in representation than what arguments can be is the "dual band"...special states that can't be reached with SET or GET. This is the home of getters, setters, type checkers, aliases... AAAAND "true unset"... the unspecialized state.

So the questions here are:

  1. Do we want more than one true unset state in the dual band, to account for END as distinct from regular "left unspecialized"?

  2. For parameters that can't be antiforms (literal args from the callsite) is it worth it to try and exploit that to use what would normally in-band as NULL to make it easier to test as if not var vs. using unset? $var

(1. No) (2. No.)

It seems to me that just letting the true unset state cover this is the best plan.

If you mark a parameter as <end>-able (maybe not the best name for the attribute... <unset> may actually be the right name for it, now that there's a state that's "not even SET") then it should be tested with (unset? $x)