#t in your case should only return 3
(i.e. all integer indexes between 1 and 3 are set to non-nil and index 4 is nil) not 440 (which would be correct if all indexes from 1 to 440 were not nil, but this is false here for index 4; all we know is that index 441 is not-nil, but it is not the highest index whose next is not nul, as you can see at ).
How the "#t" operator is computed is crazy when tables are filled in random order, or reverse order, even when all indexes are integers only...).
Ideally there can exist an optimization in the table implementation where an array (indexed by hashes) is used for collision lists of (key,value) pairs, and a second array is used to contain values directly without any collision (but possibly containing nil values): if the second direct array of values can contain nil values, then you save a lot when setting values in the table, without having t oscan the array constantly when one allocated position is set to nil (including the case where some slots may be preallocated to nil values to save the cost of reallocations): setting a non-nil value at a positive integer key higher than the last estimation would set increase an hidden "length-max" field, setting a nil value to a positive integer key value lower than the last estimation would decrease an hidden "length-min" field.
But the operator "#t" should then be able to scan from "lengh-min" to "length-max" to determine the first positive integer position with a non-nil value which is followed by nil-value: this is the only case where a table scan would be needed, and then it would set "length-min" and "lengh-max" to that determined position, and it would be very fast.
But this also means that the integer-index can then be sparse, and the standard hash table would be used for all other keys that are not positive integers or for integers that are too large without creating a large gap. The table implementation would determine when to move some integer keys from the hash table to the array, based on a simple "fill ratio" metric (the table can knows the current maximum size of the array indexed by integer, and how many positions have non-nil values, it can also count the number of collisions per slot in the hash table and when as long this is low, there's no need to extend the number of slots, but above some fill level for collision lists, the integers present in the hash table could be moved to the integer-ba