And where does it contradict what I said ? I just said that ipairs() does not enumerate only the array part, because of course integer keys in the sequence can also be in the hashed part (given the fact that the arry part is only populated by constructors, and all the rest is populated by assignments, the array part is not evolving, there's no strategy to move items from the hash part to the array part. So items of the sequences may be alternatively in each part.
All this shows that the "optimization" make in tables (using an array part) was half-done, never really finalized.
As well the order of evaluation becomes completely random. This old optimization is unsafe, in fact Lua could even live without this array part and have used only the hashed part. This would have not done a major difference. But at least it would have simplified the specification and allowed to develop a correct behavior and semantics of table constructors, with a well defined order of evaluations of _expression_ (for keys and values) and the assignment of keys in the table.
The current implementation of tables is simply unsafe. And even the hashed part is incorrectly optimized. That's very strange given that tables are a fundamental feature of Lua: there are tables almost everywhere (except arrays for upvalues, the stack of calls and the array of local variables), accessing/indexing tables is extremely frequent (including for lookup of metamethods in metatables).
