Some calculators do give higher priority to implicit multiplication (1/2 pi is not the same as 1/2*pi with Google calculator for instance), but AFAIK, this is not expected in SpeedCrunch.
Let's wait for Pol Welter's opinion, but this looks like a bug to me, as I found nothing in the evaluator code about a higher priority for implicit multiplications, and the evaluator steps for both expressions seem to indicate we missed that case in the implementation of implicit multiplications.
This seems like a tough one. Right now, I don't see an easy fix. I'll have to think some more.
The bug only occurs in expressions of the sort a/b (c). On the first pass, the evaluator will not reduce a/b, because it does not identify the implicit multiplication yet. It only sees b(, which does not match the implicit multiplication rule, so it goes on. Only after processing ), it applies the parenthesis rule to reduce the expression to a/b c. By design, the parser will now work its way back, and hence it computes b*c first.
Basically our (primitive) parser cannot correctly handle such an expression without look-ahead.
Off the top of my head: maybe outright expressions that include b( where b is not a function is a viable way out that avoids rewriting most of the parser? Not liking this approach though...
Or maybe just document this pecularity and call it a feature...