Variable's type sometimes unions with `nil` due to `if` statement with new type solver's strict mode about luau HOT 1 OPEN

Here is some context about why this is happening.

There's currently an affordance that indexing a table with an indexer returns a non-nil type. This is present because (at some point) we believed users would find it too frustrating to have to check for nil on every index, and we did not have the type refinement and typestate machinery to necessarily support inferring it automatically.

For example,

local x = { 1, 2, 3 }
if x[4] then
    fib(x[5])
end

In this case, it's not really clear what behavior is possible with the systems in place that doesn't lead to issues (either DX issues or unsoundness issues). This applies as well to function returns because you can return the results from indexing:

function getFourth<T>(tbl: {T}): T
    return tbl[4]
end

The current design point we're at for the new solver here is that indexers (and functions, as a result) can return nil without the type reflecting that, but we want people to be able to still write guards which require them to be able to compare to nil, and so, in conditional contexts, the type of function results and indexing results include implicit nil possibilities.

This lets you still write a check like...

if x[4] ~= nil then
    use(x[4])
end

without requiring refinements to be able to support a refinement per-individual-index and so forth.

All that context being said, it seems like the bug here is that it, for whatever reason, is continuing into the ensuing scope which is unexpected. The type shouldn't be changed, only temporarily viewed as containing nil in a conditional context.

from luau.