When intentionally shadowing a global with a local, if the expression refers in any way to the global itself you get a compiler error. For example, this common usecase for writing code that's compatible with Lua 5.1-5.3,

#Repro

>> (local unpack (or unpack table.unpack))
Compile error: Compile error in unknown:1
  use of global unpack is aliased by a local

(local unpack (or unpack table.unpack))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
* Try renaming local unpack.
>> unpack
#<function: 0x561b3d5194e0>
>> (local unpack (or unpack table.unpack))

This assertion was added in 59de14c to get around some possible local/global scope collision issues in the event that the mangled form of a local conflicts with that of a global. While we did know about this when the assertion was added, we decided it was worth adding to avoid bugs on the basis that global-shadowing generally isn't a great idea. However, since there are legitimate usecases like the above, it'd be a good idea to address this in the long run.

One can get around this via (local unpack (or _G.unpack table.unpack)), but this is slightly less robust; it wouldn't work, for example, in a custom environment with unpack on it set via _ENV or setfenv unless it was explicitly put on a new _G. That's an edge case, but one I think would be worth eventually fixing.

#When to fix?

This is tied into everything going on in destructure, which we've long wanted to pull apart so it isn't coupled so tightly with emitting Lua. We may need to wait until we've broken destructure up before we can remove this assertion.

originally from https://github.com/bakpakin/Fennel/issues/299