Alas, but it does have one downside... it means that out-of-range errors don't propagate easily, e.g. with the TRAP type of operation.
This is a drawback. But still... maybe the PICK dispatch could have a special signal for "not there" which is distinct from "it's there, but it's an error". And it's only at the last minute that PICK by default promotes the "not there" to a definitional ERROR!.
Then, you can use :foo.^bar as a syntax which means "turn to null if not there" (e.g. don't do that last minute conversion, make a null instead), and still not conflate this with in-band errors the way that try foo.^bar would.
What would happen from this is that bad picks couldn't give you more descriptive errors than "couldn't pick BAR from FOO" in their missing field cases, but true ERROR! values could come back from picks and not be conflated.