Note what wouldn't be the same here:
>> get block.($1)
** Error: can't PICK $1 in block
We don't know what $1 does. Most likely errors (bound INTEGER! are not likely to be a good idea, but, who knows). Even if bound integers were decided to be okay, $1 would produce 1.
This also would not be the same:
>> get block.('$1)
** Error: can't PICK $1 in block
That's trying to use $1 directly as the "picker" and is a completely different thing. That would be for like if $1 was a key in a MAP!. It has nothing to do with binding.
When you aren't using a GROUP! like that, and things are just appearing literally in the tuple, they are dialected.
That means this also would not work:
>> get pick block '$1
== 10
There'd have to be a separate out-of-band parameter to PICK to do this, like a :BIND refinement or something.
>> get pick:bind block 1
== 10
CHAIN!-based compound SIGIL! won't work here
Let's say you're indirecting through a variable:
>> n: 1
>> block.(n)
== x
That has a shorthand (not just shorter in terms of one character, but more efficient as it can bypass the evaluator, and doesn't use a list type which makes a separate allocation):
>> block.@n
== x
If you want to ask for binding, then this is no good:
>> get block.$:@n
== 10
That's seen as a 2-element CHAIN! of [block.$ @n], not a 2-element TUPLE! of [block $:@n], due to the hierarchy of sequences.
"And nothing of value was lost", that looks much better as:
>> get block.$(n)
== 10
I've proposed that the sequence mechanics might optimize this pattern so that (n) in a sequence doesn't actually cost more than @n, and this is another motivator for that optimization.