Note that even when this behavior is expected, this code is not
necessary bugged:
insert(t,n,somefunction(...))
insert(t,n,somefunction(...))
insert(t,n,somefunction(...))
It's about the n:
if you say 'not necessarily buggy' that is hedged enough to be true.
But already your 3 line snip can lead to insert() making
replacements instead of pushing existing values up.
You could for only /one/ nil, /still/ end up with a table only
holding 1 value, not 2.
If you have these n:
insert(t,1,somefunction(...))
insert(t,2,somefunction(...))
insert(t,2,somefunction(...)) -- 2 again!
Intuitively, of course, the last line is expected to always push the forelast's value up.
But instead, it /deletes/ and overwrites that forelast value, if somefunction(...) returned nil in the /first/ line.
That's pretty nasty in my eyes. Your second line's value is gone by virtue of the combination of the first and second. Only 'inserts' in play:
insert(t,1,nil)
insert(t,2,'a')
insert(t,2,'b') -- 2 again!
-- table is now { 2:'b' }
Henning