First, thank you for considering my arguments this late in the release schedule. I appreciate your measured reply.
I still think that keeping functions composable is preferrable to the decrease in readability, and I still disagree that option B is more predictable.
On option B being less predictable, no one in this discussion so far has mentioned the behavior of function syntax on the left side of an attachment. In option B, why does abs(a)^b work, but not a^abs(b)?
Or why, when I remove the space before the parens in the next expression, does the function call act like one element? √abs (a)^b groups as √(abs) (a)^b, while √abs(a)^b groups as √((abs(a))^b). If option B were fully consistent, we should require parens around the call for it to work.
So I still disagree, but this is becoming more of an argument in taste than in truth. And at this point I don’t really expect to change your mind.
So if you want to go with option B, I can accept that.
However, a new case that hasn’t previously been considered and whose behavior has regressed with #6442 has now come to light in discussions on Discord (specifically the parsing precedence in $ 1 / f_a(x) $).
As we don’t want to put the burden on users to migrate their documents twice, we have thus decided to revert and postpone the change. That said, we are still committed to fixing the rendering of $f_i(x)$.
In particular, we are planning to prioritize a more holistical reconsideration of all edge cases and issues of the current math syntax, so that we can make one confident change rather than spread-out, disruptive fixes.