This looks odd - you're doing ToList on the enumerable (into values), only to then iterate over values and populate another list from it (processedValues); any reason to not just do foreach on the IEnumerable (instead of the for just below), and populate processedValues directly from that, skipping the additional values copy in the middle?

(the one problem with this is the we'd move the generic list creation with MakeGenericType out and do it always, as opposed to only when there's a NULL today. But MakeGenericType is a single constant cost, whereas doing another ToList is O(N)).

BTW doing a ToList() like this would indeed make sense if it prevented double-enumeration of the enumerable (since enumerating an enumerable can be arbitrarily heavy, depending on what it actually does). However, the change as proposed here doesn't seem to prevent double-enumeration anyway: if no NULL is encountered, we just exit below (processedValues is null), and the enumerable will be enumerated again at some point later.

Finally, ideally enumerables would be enumerable/materialized very early on - in the funcletizer - so that can later just assume we have a List everywhere. That would prevent us from having to worry about this in every single place in the query pipeline. I think that would be my preferred fix.

Note: I could see your ToList solution making sense for the patch, to really keep the change super-minimal. But for 11 let's discuss the best way forward.

Honestly I never understood the lazy creating of processedValues...