So I rather quickly ran into the fact that PICK is shared code with what you get when you are using a tuple. So pick block 3 acts like block.3, and pick obj 'field acts like obj.field, etc.
But there's an important difference: obj.field can run a function. And if you write try obj.field the expectation is that your TRY is processing the result of that function...not errors arising from the field selection itself. :-/
A thought that crossed my mind was that perhaps /obj.field could be a notation for "field presence is optional" and give back null if it's not there, and /block.3 could do the same thing. I'd often thought that refinements were wasted as being inert, and since they exist in other places meaning "optionality" then something like this could be an application.
But new APPLY uses inert refinements to good effect, so I'm reluctant to pursue something like that.
Long Story Short: There's no real reason why (pick block 3) and (block.3) can't have different error modes, but (try block.3) can't defuse a definitional error for the pick without generating a disconnect from (try object.funcname).
For the moment, picking things that aren't there gives null on blocks, and errors on objects. It's a bit misshapen but some code would be more laborious to write if things like block.3 would error, forcing you to use (try pick block 3). And you really would have to put it in parentheses in many cases, because expressions like (block.3 = 'foo) would require ((try pick block 3) = 'foo)
Maybe it should be laborious? Anyway, food for thought.