A while back, if memory serves me correctly, sorear++ pointed out the operator-y nature of the [] and {} postcircumfixes and suggested they should perhaps be subs, not methods. This makes a lot of sense in so far as adding new ones is a language tweaks. However, I believe that making a change like this is important for optimizability.
Today, looking up an array element is two method dispatches, first to a postcircumfix and then to at_pos or at_key. The late bound nature of these makes optimization difficult. Inlining of subroutines is already done by the Rakudo optimizer. Inlining of methods at compile time, on the other hand, is much harder. Nothing is closed or finalized by default, meaning at best a static optimizer can emit a speculative inline with a fallback. A fancy JIT or, on things like the JVM, doing our own runtime tracing and producing specialized JVM bytecode, are possible. However, something as fundamental as array access being so hard to optimize is a bit of a design smell.
Switching the postcircumfixes to subs immediately makes the first dispatch open to compile time resolution in the normal, untyped case. This is an immediate win. It still makes it easy for those implementing simple custom array types, as that just needs overriding at_pos, as happens today. Doing custom handling of slicing is still possible; it's just a case of writing multi subs instead.
The case gets stronger when considering native arrays. My expectation is that we will forbid mixing into native arrays just as we do with native integers and so forth. Thus there should be nothing late bound with reading and writing to a native array. This combined with the suggested change to postcircumfixes would mean that multi candidates that work with native arrays can do lower level things right off, not needing the method call to at_pos since it could never get overridden anyway. Combined with multi sub inlining, the statically produced code will already be pretty good before the optimizer gets hold of it.
Other fallout changes are that the Positional role should most likely require an at_pos method, and Associative an at_key. Potentially bind_pos and bind_key too.
That does leave the status of postcircumfix:<()> needing some thought. That is probably not too hard to figure out a way forward on.
tl;dr I've been pondering efficient native array (and general array) code-gen for a while, and this change would make it much more achievable, make the language a little more regular, and have very little ecosystem impact. I'm throwing it out for shooting down, improving on, approval, etc.
+1