Awkward results from the length operator with multiple nil entries

[MCJack123]

While working on CraftOS-PC I noticed that Cobalt can give inconsistent results with the length operator when there are multiple nil areas in a table. This appears to be due to the binary search algorithm landing on specific entries and assuming they're on a boundary (which is true). Here's some examples of different results from very similar tables:

According to PUC Lua, these should be returning 9, 8, and 9 (as the contents are statically allocated*). A user might expect all three to resolve to 3, as the first boundary is at index 3.

I know the specification for the length operator is a bit ambiguous, and that these results are technically correct. However, they can be wildly variant, and since users often think it returns the boundary of the first nil they might be caught off-guard with statically allocated* tables of this nature. I'm not sure how this will affect speed, but it might be better for user experience to either a) return length using an array search first, then fall back on hash search (as PUC Lua does), or b) do a linear search (which is slower but more reliable to the user).

---

^{*When I use "statically allocated" I refer to creating a table with pre-filled slots, including nils in between. Not sure exactly how to refer to this, but whatever.}