oh no, no clue about the 5 windows failures with error types. what could that be?

namespace failures from my side

and I still don't understand the slevomat failure. it seems to be also related to the unions of constant arrays where some properties end up being optional in the resulting array.. but if the type is correct, maybe the array_key_exists extension really should not specify constants? not sure..

has been fixed by Ondrej in the tagged unions preparations

and the prestashop error is something I'm still looking at. UPDATE: the union normalization is adding the non-empty-array type as in #1537 (comment) :/

also been fixed by Ondrej

found out a bit more about the prestashop errors at least. looks like because of the if condition with empty at https://github.com/PrestaShop/PrestaShop/blob/6c3797271697278b31e2bd0905d54cea6131d335/classes/pdf/HTMLTemplateInvoice.php#L438 there are multiple scopes and the final scope, that has the correct unset union type, is being merged with the current one that has the original type of $breakdowns. Basically this leads to smth like array{foo: array, bar: array}|array{foo: array}|array{bar: array} where the first shape is the original type and the other 2 are the unset unions. The outcome then is array{foo?: array, bar?: array}&non-empty-array which makes sense I guess, but leads to the Variable $breakdowns in empty() always exists and is not falsy. below. hmm
I think this is a case where the non-empty-array intersection should not be there, but since it comes from scope merging I'm unsure what the problem is exactly.

irrelevant, since it has been fixed by Ondrej as mentioned in the previous comment. But I extracted a test case based on that and put it here just to be sure.

this is now ready. has been unblocked by recent changes basically.
maybe it even helps with the tagged unions or with in_array specification. if not it improves things a tiny bit I guess :)

Really nice, thank you :)