It is only an implementation issue if it is possible to solve the issue.
Nobody has ever built a garbage collector that does not slow your program down or cause it to use vastly more resources than it would otherwise. (Claims to the contrary are always implicitly caveated).
Given that this is the case, it really does start looking like a language issue. Yes you can rearchitect the GC to care more about locality, but you are just pushing the dust around on the floor: you will find a different problem.
Your comment isn't wrong in itself. For any GC you can write some program that exploits its weaknesses
But you could deal with this bug in various different ways. For example, here you could be implementing erlang queues so that the length is stored, instead of checking the length. You could implement hibernation differently. You could implement popping differently. There are probably ideas from people who know more than nothing about erlang.
Anyways, I don't think this particular issue was really an issue with the concept of a GC'd language, more of a specific bug issue.
My point is that you can solve this one symptom but your program will have many other problems due to GC (provided it does a lot of work). It is like whack-a-mole in that there are always more moles.
Nobody has ever built a garbage collector that does not slow your program down or cause it to use vastly more resources than it would otherwise. (Claims to the contrary are always implicitly caveated).
Given that this is the case, it really does start looking like a language issue. Yes you can rearchitect the GC to care more about locality, but you are just pushing the dust around on the floor: you will find a different problem.