It was discussed and for a while it was my preferred possible fix. However, a number of legitimate potential issues were raised in that thread and elsewhere (it’s been discussed so much it’s hard to keep track). I won’t repeat them here.
Jeff prototyped it and we played around with it for a while to get a feel for the behavior. It was in fact kind of fussy and brittle. When you account for all the possibilities, the rule is not so simple to explain or to implement (that patch adds an enormous amount of Scheme code to the parser). It also fails to address the fact that when someone assigns to a variable in a loop that is already a global, it’s actually ambiguous what they mean: did they intend to clobber the global, or did they want a local that shadows the global? Yes, we could make it work in some cases like this example, but that wouldn’t address the deeper ambiguity. So after a lot of discussion, Jeff and I decided against it. It just didn’t feel right.
We came up with the current solution as an alternative and some time later prototyped it. In the REPL it uses a proven heuristic from 0.6 and just does the convenient thing. In a file, on the other hand, it forces you to disambiguate in exactly the case where the heuristic is necessary and where the problematic ambiguity exists. This one “feels right”: it’s relatively simple and it prevents people from accidentally writing broken and/or confusing code. In PkgEval runs (with the warning made fatal) we found that it hardly ever triggered a warning in package code, and when it did, that code was usually actually buggy.
I’m also very done with conversations on this subject unless they are “This works so well, thank you very much!” 