Yes, I avoid making assumptions about invariants across mutation calls, that's just a bad idea.

> For slices, we know that x[0] will always print 5 until the value of x is reassigned in some way.

Unless an other goroutine is stomping on your backing array anyway.

> It would have the same problem the map does: you'd have to update any pointers into the slice to point to the new slice, otherwise the semantics of the program changes. That is not something the GC currently does, and would require an awful lot of metadata and scanning.

Yes. So maybe we could ignore that useless strawman?

> I'm not sure what this is referring to.

To what I'm quoting.

> I was trying to say that keeping the flexibility to reallocate the backing store of the map during GC

That sounds less like flexibility and more like "let's make the GC slower and more complex for no reason".