It looks like the reason for using SingleIterator (with null argument) instead of EmptyIterator is related to returning empty list, compared to returning null in EmptyIterator when calling computeNext, is that so, why not just use EmptyIterator instead and let the customer deal with the null?

EmptyIterator does not return any item. It is endOfData() immediately. This one does return the empty list. Some combinatorics algorithms want nothing on empty while some others like the topological sort want an empty result on empty input. We thus need both I think.

why are these tests commented out?

I believe we can immediately return IntersectionResult.noViableIntersection() if the resulting intersection compensation is impossible, correct?

No. It may be that we are currently impossible but that there is a common ordering (in fact there must be one for the follow up to work). If there is no common ordering the result will be discarded. If there is a common ordering but it is currently impossible to (think 2 out of 3 aggregate functions are satisfied), we want that intersection access to survive because otherwise we would never get to the intersection that creates the one where we get 3 out of 3.

It would be nice to add some comments explaining the handling of matched group by aggregations and groups here.

I don't think it is possible to retrieve an IntersectionResult which non-empty list of RelationalExpressions and null-common ordering, if we examine the code flow above.

Having said that, we could probably cleanup the code, such that we can remove the hasCommonFlag maybe?

No, You can have a common ordering but no expressions due to the compensation being impossible. You still want to signal the caller to keep this intersection (even though you didn't produce a single expression) in the sieve so you can potentially find a bigger intersection that is not impossible.