Ну почитал: https://github.com/golang/go/wiki/LoopvarExperiment

1) This test aims to check that all the test cases are even (they are not!), but it passes without GOEXPERIMENT=loopvar. The problem is that t.Parallel stops the closure and lets the loop continue, and then it runs all the closures in parallel when TestAllEvenBuggy returns. By the time the if statement in the closure executes, the loop is done, and v has its final iteration value, 6. All four subtests now continue executing in parallel, and they all check that 6 is even, instead of checking each of the test cases.

2) This kind of unintended sharing bug hits all Go programmers, whether they are just starting to learn Go or have been using it for a decade. Discussion of this problem is one of the earliest entries in the Go FAQ.

И даже их https://github.com/golang/go/wiki/CommonMistakes

Это все какие-то детские болячки тех, кто не понимает, как работают замыкания. Хотя этой статьей они сами по сути признают, что это не очень-то очевидно и "hits all Go programmers". И теперь они меняют семантику за счет дополнительных аллокаций, чтобы фиксить "латентные баги":

"However, in some cases, an extra allocation will be added. Sometimes, the extra allocation is inherent to fixing a latent bug."

Хотя и это не всегда:

"The vast majority of loops are unaffected. A loop only compiles differently if the loop variable has its address taken (&i) or is captured by a closure."

Т.е. компилятор теперь будет разбираться, где надо плодить копии, а где не надо. И все это может поломать старую совместимость (хотя у них там будут предпреждения, что нужно сходить и проверить).

Это ли не выглядит косяком в изначальном дизайне, который фиксится с помощью костылей?