Note that the result of #t is also VERY unreliable on tables that contains sequences with holes: it may stop counting prematurely or not, randomly, depending on the number of items with integer keys after the first hole, or the number of non-nil keys before. So #t stops counting when it encounters some holes, but not all (I think this is related to how keys are hashed internally: tables may store integer keys partly in an unhashed array, partly in the hash (even for tablets that were constructed once and never modified), because the two parts are not balanced to choose which part will store the value associated to the integer key.
If something must be deprecated it is #t (except when t is a string), not ipairs(t) which is more reliable as it can effectively enumerate all integer keys (in a sequence or not), but note also that ipairs(t) on tables is not warrantied to return all keys in ascending order (this would require collecting all keys into an internal sequence table kept in the iterator, then sort that internal sequence of keys, before possibly compacting the successive ranges into another sequence table containing the list of ranges that will be counted one by one by the iterator's next() operation...)
What is intriguating is that pairs() and ipairs() have no parameter to indicate that we want a specific order or not for the enumeration. It should not need to sort them by default, unless we provide a function to compare keys and sort them.
