UPDATE 2025: This used to have to be:
>> [pos :result]: eval:step pos
== ~null~ ; anti
>> result
== ~null~ ; antiform <- conflated with result of null
But I updated it in light of the new attitude regarding things like VOID assignment
It's still an option to mark the argument as optional via leading-colon, and get null. But if you choose not to mark it, then your variable becomes "true unset" (which cannot be the product of an evaluation).
I think the "true unset" variables strike a balance, giving the desired guardrail while keeping the source looking nice and neat!
It might seem "more dangerously permissive" to not panic by default when you're unpacking a pack with too few values. BUT I think when you look at it holistically, it's probably safer in the long run. Because rather than force you to knee-jerk add a leading colon just to say "yes, I know it might be too few items, make a null if it is"... it's keeping you from conflating a lack of a value with synthesizing an "in-band" null... and I imagine that could wind up being more important, because it catches unintended uses of a meaningless state.
Additionally... consider that a lot of EVAL:STEP calls probably want to be generalized, and process ^META results. If you had to say something was both optional and ^META:
[pos :^result]: eval:step pos
If you can avoid that, so much the better:
[pos ^result]: eval:step pos
Improvements, a little bit at a time...