It has worked out that the @ symbol makes the most sense for reuse existing binding... simply because we're not relying on something completely invisible.
for-each 'x ... ; the FOR-EACH receives a WORD!, probably unbound
for-each $x ... ; the FOR-EACH receives a WORD!, probably bound
for-each @x ... ; the FOR-EACH receives a THE-WORD!, probably bound
It feels more in control to be going on the basis of a sigil that is carried with the word...especially because it goes along with the distinction of for-each [a @b] ... where both have bindings available, it's just only one that's being heeded.
So this will be pushed out systemically to LETs and multi-return blocks. With multi-return, that means having to switch to FENCE! for "circling" a slot to be the primary output value. (Hopefully not too much longer until FENCE! is in...)
Now that we have SIGIL! as a datatype, decomposing things that way is a generalized option. But I don't want to give up too easily here... so let's look at another avenue of attack...
One thing about multi-return is that it's going to be recursive:
[[a b] [c d]]: pack [pack [1 2] pack [3 4]]
Hence these are synonyms:
[a b]: ...
[a [b]]: ...
I think that can be leveraged here, if ^META applied to a block means "apply this to everything in the block".
^[a b]: ...
=>
[^a ^b]: ...
So you could write [a ^[@b]]: and that would mean reuse the b variable, but also make it ^META...and it doesn't feel that contrived to me.
The reverse could be possible as well ([a @[^b]]:). But that isn't as appealing to me for some possibly arbitrary reason. Though if I'm looking for an inkling of a reason for why it's inferior, it couldn't apply on the outermost layer, because the sigil indicates "as is", even for a set-block:
>> @[a b]:
== @[a b]:
So I think the simpler rule here is only to allow the meta sigil to distribute over blocks. It seems to cover the bases.