> I think it's confusing and counterintuitive that putting parentheses > around a subexpression completely changes the meaning. I don't know of > any other programming language that behaves that way,
I take it that you also don't believe that "2 + 3 * 4" should yield different results from "(2 + 3) * 4"?
In that expression "2 + 3" is not a subexpression, although "3 * 4" is, thanks to the operator precedence rules.
I could get behind offering an alternative notation, eg "a.b->c does the same thing as (a.b).c", if we could find a reasonable notation that doesn't infringe on user operator namespace. I think that might be hard to do though, and I don't think the existing notation is so awful than we should break existing operators to have an alternative. The business with deprecating => operators a few years ago had the excuse that "the standard says so", but we don't have that justification here.
This is one of those areas where it will be difficult at best to do something which makes things work the way people expect without breaking other cases. I certainly would like to be able to use . to extract a field from a composite value without parenthesizing everything, but given the potential for having a schema name that matches a table or field name I would want to be very careful about changing anything.