When the problematic query is compiled, the byte code for the UnionNode is generated twice. I'm not sure why it's needed twice in this case, but it looks like the byte code generation in general is prepared for it, so I assume it's OK for now.
The right side of the UnionNode contains a ProjectRestrictNode with the predicate 1=0. The first time PRN.generate() is called, predicates are taken out from restrictionList and put into restriction or constantRestriction, depending on the nature of the predicate. restrictionList is nulled out. The second time PRN.generate() is called on the same object, the predicates are supposed to be taken from the restriction and constantRestriction fields instead of the, so all the predicates should be preserved between the invocations.
However, PRN has a method nopProjectRestrict() which checks whether the PRN actually restricts the result. This method checks if there are predicates restrictionList and restriction. But since 1=0 is a constant expression and has been moved to constantRestriction, the method doesn't detect that the PRN actually does restrict the result, and the code to restrict the result is not generated.
The attached patch makes nopProjectRestrict() check the constant restrictions as well. This makes the query return the expected result. The patch does not add any regression tests, nor has any regression tests been run with the patch.