"foo"b being an error is good because it would be confusing if it meant multiplication when a"foo"b is a nonstandard string literal with b as an extra argument.

same feeling here, I think if people accept 2x in Julia is (2 \times x), it is intuitive that 6/2(2+1) = 6 \div 2(2+1) and 6/2*(2+1) = 6 \div 2\times (2+1)

But it wouldn’t be inconsistent (but of course breaking) to disallow 2(2+1), since it can be interpreted as function call syntax. I find 2x to be very nice syntax, but dislike 2(2+1).

The reason I make this point is that it was argued that one cannot have the former without the latter.

Yes, that is the current situation. But I was saying that it is possible to like 2x without liking 2(2+1). The language didn’t have to have both. It does have both, but it didn’t have to.

Wolfram language uses square brackets for function calls, apparently to distinguish from the implicit multiplication syntax. Julia chooses not to use a function call syntax that’s alien to programmers from other languages, though this pragmatic compromise makes the syntax a little bit more ambiguous. Personally, I prefer to explicitly type out * operators when using either language.

That’s exactly why Wolfram Language uses double square brackets for array indexing: a(2) means a*2, a[2] means calling function a with argument 2, and a[[2]] means the 2nd element of the array a. Fully avoiding syntax ambiguities related to implicit multiplication has caused a chain reaction which produces a LOT of strange syntax in Wolfram.

Yeah, a[[2]] would have been ambiguous in Wolfram Lang if [2] means a vector of one element 2, but Wolfram actually uses curly brackets instead for vectors, making its syntax even more unfamiliar to most people. By allowing syntax like 2(x+y) in a fully unambiguous way, it’s surprising how much the rest of the syntax choices become constrained in Wolfram Lang.

This looks consistent to me, if you are willing to forgo the convenience of things like 2(x+y). I don’t mind typing 2*(x+y), and in fact, 2*x either.