I dislike overly-complex code as much as anybody, but this sounds to me like there is some known work that could be done to address the problem, and yet the response is to reject it and continue to declare the problem unsolved. We might have to just hold our noses and write the ugly code.
If these iterator consumers are currently very simple, I’d guess they don’t support heterogeneous iterators generally — is that the case?
We might be able to help this situation with an iterator trait. In particular, even an iterator that doesn’t have a known eltype might have a good guess at which parts of its results are missing-able. The trait could be implemented for tables as well as Generators over tables. Example:
hint = wider_type_hint(iter) # this might return e.g. Tuple{Union{}, Missing, Union{}}
elt = get_next_value(iter)
eltype = promote_type(typeof(elt), hint)
result = Container{eltype}(...)
The good part is that wider_type_hint can correctly default to Union{} for all iterators.