@mc
Being charitable to the Casio, I suppose it's possible that the multiplication is only getting higher precedence due to being implicit, i.e. such that "a / bc" is "a / (b * c)" and not "(a / b) * c". I could maybe accept that, as long as "a / b * c" is correctly interpreted as "(a / b) * c". However, I wouldn't ignore the possibility that the Casio is actually giving higher precedence to multiplication in general, which is what I'd be more worried about.
@mc
Thanks for that link. The real answer is that, although PE(MD)(AS) does require explicit multiplication and division to have the same precedence, it does not define the semantics of *implicit* multiplication. As your linked page mentions about halfway down, there are two interpretations in common use. Any ambiguity from this should be avoided by using explicit multiplication. Most programming languages enforce this by disallowing implicit multiplication at all times.
My guess is that Casio is using PE(MD)(AS) correctly, and is using the "algebra class" interpretation (i.e. implicit multiplication has higher precedence) to make that model of calculator more useful to algebra students.
Meanwhile, the Android calculator would naturally follow the "elementary school" interpretation (i.e. implicit multiplication is the same as explicit multiplication) to appeal to a more general audience.
So, both calculators are correct for their intended purposes.
@mc
Julia is an interesting case. Implicit multiplication is only allowed where it doesn't clash with the function syntax, it has higher precedence, and it forbids whitespace. https://docs.julialang.org/en/v1/manual/integers-and-floating-point-numbers/#man-numeric-literal-coefficients
julia> x=9; y=2;
julia> 2x/3y-1
2.0
Meanwhile, the Wolfram Language allows implicit multiplication in general, but apparently with the same precedence as explicit multiplication, and whitespace is required. https://reference.wolfram.com/language/ref/Times.html
I appreciate that both languages have rules about whitespace that make the semantics more obvious. The approach used in Julia seems more useful, though.
@mc
Clarification: for some (most?) programming languages, the main motivation for not allowing implicit multiplication might actually be to simplify parsing, with preventing ambiguity being more of an added bonus.