> Consider (foo)=bar.

Can't we just forbid that? I would have - that's why I wrote "varname" above, and not "expr".

> Also, += and friends would have to change to read+modify+write bytecodes

You mean unsugaring "x += a" to "x = x + a" for the bytecode? Seems like the cleanest solution to me anyway.

Concerning bytecode (edited, after a bit of thinking): Okay, first we do have to reverse the execution order in any case. So if someone intends to do "bla()["bla"] = blub()", bla must be executed after blub. Otherwise we might have to re-code the whole reference holding and updating stuff inside the bytecode interpreter.

So I guess the best solution would be to have bytecode producing values (onto the stack) and bytecode producing references (into a local variable in the bytecode interpreter). The second one would be used for "a = b", in the style of "(b bytecode) AB_LOCALN_R AB_SET". The local variable would be immediately read by the next bytecode, which is fast enough that the reference is still guaranteed to be valid.

> If we impose the rule that all functions with the same name have the same type

That doesn't really sound very tempting. Do we want to argue that functions using reference parameters are somehow likely to have unique names?

I do see your point with array references being required, however. Maybe change arrays to reference sematics (yeah, icky, I know) or require that people use

var bla = { a = [...huuuge array...] };
ChangeHuuuugeAray(bla);

? ;)