Thanks for reporting, that looks like a bug in the type system. /cc @neelance

Both of these lines fail too:

fmt.Println(map[string][2]float64{"a": {1, 2}})
fmt.Println(map[[2]float64]string{{1, 2}: "a"})

So I guess it is reflection related problem.
I haven't been able to reproduce it without a map or array (using a slice in place of either works fine).

This is as far as I get in terms of a minimal reproducer:
reflect.ValueOf(map[string][2]float64{"a": {1, 2}}).MapIndex(reflect.ValueOf("a"))
The result is: panic: an.$set is not a function

If the map does not contain a value for the requested key this does not panic. Which makes me wonder if I missed some way of crashing using reflect only on [2]float64, but I couldn't find one.

There is the case that a value's ptr is a JavaScript native array and the kind is $kindArray, and mapassign accepts a native array and fails to call its $get function, which doesn't exist. When is a $kindArray value's ptr is a native array?

Perhaps, ptr member in reflect package's Value and ptr variable set at $newType are confused at SetMapIndex and mapassign?

Perhaps, ptr member in reflect package's Value and ptr variable set at $newType are confused at SetMapIndex and mapassign?

The above guess might be wrong. Please ignore...

My understanding is: https://gopherjs.github.io/playground/#/3BcYDllnf7

EDIT: My question: it is assumed that $get can be called from a given unsafe.Pointer value to mapassign. Is this assumption correct?

It appears that this is no longer reproducible in the current GopherJS 1.16.x versions. Please feel free to reopen if I'm mistaken.