That's what I defended. The internal optimization of moving some hasved integer keys and value pairs outside the hash into an indexed array should never have any impact on what sequences should enumerate in Lua or on the value returned by #t which should always be the smallest positive integer key whose value is null or unset, minus 1. The optimization that uses an array should be consistant. #t can still just return an index computed and cached efficiently in the array part, provided that if this cache does not find the relevant integer, an hashed search will scan the hash store to find the relevant index and maintain that in a consistant cache within the hidden table storage structure. That's not what is done, so sequences have ill behavior with unpredictable results. To have lredictable results, then applications have to segregate the tables they use for sequences for those that are just random dictionnaries of unordered properties for generic objects.
Then comes the problem of objects that have still no synthetic prototypes that would allow their properties to be acced faster using array indexing rather than slow hashing with management of collisions in a loop. This is a serious security concern.
