Logically, there's a layer of "evals" missing here. Compare to the two original col_ctr loops above.
It COULD be that these evals are just pass-through TVEs AND it COULD be that even if they aren't, they are merely "trading one null for another null" as most expressions have that effect. But I'd be more comfortable if the null tuple was produced by a formal process of:
    1) Allocating a standalone tuple having the inner tuple's schema.
    2) Explicitly setting all of its columns to a suitable null value -- that seems useful to define as a TableTuple method.
    3) Cache the value of m_outputExpressions[col_ctr]->eval(null_tuple, NULL) for all col_ctr >= outer_col_count to generate EITHER a vector of NValues -- OR store them towards the end of a dummy tuple matching outputTable's schema -- but I don't see the point, really, unless it can help to optimize the NEXT step -- perhaps by some kind of offset tuple data memset trick.
    4) Setting the ending attributes of the output tuple for each unmatched outer tuple to these cached values -- possibly with another TableTuple method.

Note that steps 1-3 could be done once (on demand as needed) and only the 4th step would need to be repeated.