the 11 failing "normal" tests are expected, it's the regression test that I mentioned in the description

the 4 phpstan failures seem to be related to recent changes on 1.9.x

and the interesting part I wanted to check are the 2 integration failures. I think both of them are fine.
e.g. https://github.com/sebastianbergmann/phpunit/blob/93d4bf4c37aec6384bb9e5d390d9049a463a7256/src/Framework/TestCase.php has 4 ReflectionException dead catches instead of 2, because in all cases the class is existing. but I have no clue how and why this would show up here now 😅
and the PMMP failures are related to the LevelsIntegrationTest that was needed here too but I think is correct. the offset can be non-existent in the union dim. the stringOffsetAccess levels test also shows that those were already reported as potential invalid keys.

I don't love this very much, I spoke against dressing flattenTypes as a new method here #1687 (comment). My problem with that is that it doesn't describe any specific use-case, and can be wrongly used or implemented. I'm for methods that feel more like a specific use-case.

BTW we don't have to drain all array use cases before moving on, I'd rather address wrong usages that are most common, like:

• instanceof TypeWithClassName
• TypeUtils::getDirectClassNames()

To me it feels like these usages should be replaced with Type::getObjectClassNames(): array

ok, got you. I started having this obsession a while ago, where the final goal is to get rid of ConstantArrayType::getAllArrays() 😅

the mentioned getDirectClassNames() cleanup sounds like a good one, yeah 👍