There's an open spec issue about this type of bugs: https://github.com/tc39/ecma262/issues/467

Basically we never invested time to implement the exact spec algorithms, because it leads to regressions (bloats byte code; worse error messages). And the spec was never changed to follow the implementations, because it requires reworking the Reference type (and some folks still prefer strict left-to-right evaluation).

Those two reasons: bloats byte code and worse error messages, sounds like a good reason to change the spec. I understand that this might take some spec work, but since this is part of the stream this might be interesting for people to see. Is it worth the time investment to change the spec?

It'd be easier to convince TC39 to change the spec if implementations all had the exact same semantics, but they're also all slightly different. :-/

Just to expand on "bloats byte code and worse error messages", for dis(function(o, p, v){ o[p] = v }), we're currently emitting

GetArg 0                        # o
GetArg 1                        # o p
GetArg 2                        # o p v
SetElem                         # o[p]

which has the minimum number of operations.

Per spec and with our current set of byte code operations, we'd need to emit:

GetArg 0                        # o
GetArg 1                        # o p
Swap                            # p o
CheckObjCoercible               # p o
Swap                            # o p
ToPropertyKey                   # o p
GetArg 2                        # o p v
SetElem                         # o[p]

which doubles the amount of byte code operations, so that's not really acceptable. Furthermore CheckObjCoercible will report TypeError: null has no properties when o == null, whereas we're currently reporting TypeError: can't access property 0, o is null. The less informative error message is already today visible:

js> null[0]++
typein:1:1 TypeError: null has no properties
Stack:
  @typein:1:1
js> null[0]+=1
typein:2:1 TypeError: can't access property 0 of null
Stack:
  @typein:2:1

To reduce the byte code bloat and also still report a proper error message, we'd need to add a new operation which combines CheckObjCoercible and ToPropertyKey:

GetArg 0                        # o
GetArg 1                        # o p
PrepareSetElem                  # o p
GetArg 2                        # o p v
SetElem                         # o[p]

But that's still a 25% increase in the number of byte code operations.

Depends on D78905

Depends on D86231

I have the worst ideas for optimization

Depends on D86232

Depends on D86233

Depends on D86234

Depends on D86235

Depends on D86236

Depends on D86234

Depends on D90695

The leave-open keyword is there and there is no activity for 6 months.
:ystartsev, maybe it's time to close this bug?

This has been addressed within the spec iirc (https://github.com/tc39/ecma262/pull/2267), so we can close this.