Beside obviously funny code like {1, [1]=2}, the issue is more serious with this code, not created just for fun by hackers:
{ [k(1)] = v(1), [k(2)] = v(2) }
Whose result is also completely undefined. There's no warranty that you'll find the two values v(1) and v(2) even if they are non-nil and different. The situation gets even worse if one of these values is nil, as you could get a table containing no value at all even if the second value was not nil.
Constructors with dynamic key expressions are flawed. Permitted and documented by the syntax and the standard parser. But you cannot know what will be actually in the table. And it is impossible to track at runtime even if you overload the __newindex metamethod.... Which you cannot even do with tabke constructors that always return a table without metatable.
The only safe way to initialize a table with keys is to create an empty table, then populate it in a loop item by item. The keys and values you'll use in the loop however can be stored in an unkeyed table constructor (creating sequences with implicit integer keys)
Explicit keys with dynamic values do NOT work at all as expected with the constructor.
But populating a table in a loop is slow and costly, it overused the memory locator and stresses the GC.
