I think that somehow, you need to handle multidimensional arrays too. The new error in CI is a false-positive: https://github.com/composer/composer/blob/3ae111140facdba8ae82adcd1085e4adfc7d715c/src/Composer/Util/Http/CurlDownloader.php#L230-L236

 ------ ----------------------------------------------------------------- 
  Line   src/Composer/Util/Http/CurlDownloader.php                        
 ------ ----------------------------------------------------------------- 
  232    Offset 'ssl' does not exist on array{http: array, ssl?: array}.  
  232    Offset 'ssl' does not exist on array{http: array, ssl?: array}.  
 ------ ----------------------------------------------------------------- 

@ondrejmirtes
It is a regression, but is a expected behavior for me.
This PR could make the type of $option in foreach more specified (correct? I think) compared to the current playground result which lead to this regression.

To solve this case we need to implement type specification of isset with expr key.

Maybe I should solve these issues before this PR to avoid these kind of regressions (I'm looking into these issues but not easy to solve...)
phpstan/phpstan#6508
phpstan/phpstan#7000

I'm happy with the improved type inference of this PR, I just don't want this code https://github.com/composer/composer/blob/3ae111140facdba8ae82adcd1085e4adfc7d715c/src/Composer/Util/Http/CurlDownloader.php#L230-L236 to report these errors:

 ------ ----------------------------------------------------------------- 
  Line   src/Composer/Util/Http/CurlDownloader.php                        
 ------ ----------------------------------------------------------------- 
  232    Offset 'ssl' does not exist on array{http: array, ssl?: array}.  
  232    Offset 'ssl' does not exist on array{http: array, ssl?: array}.  
 ------ ----------------------------------------------------------------- 

Because the code involves expressions like isset($options[$type][$name]), this cannot be solved entirely by the typesystem. But I think it could be solved in NonexistentOffsetInArrayDimFetchRule / NonexistentOffsetInArrayDimFetchCheck. Because surely, isset($options[$type][$name]) makes $options[$type][$name] appear in MutatingScope::$moreSpecificTypes. So this rule/check could ask Scope::isSpecified() about this to prevent the false positive.

I had investigated this issue in #1187.
The problem is, because type of array before and after isset doesn't change in these cases 83fe253, phpstan/phpstan#7000

Because surely, isset($options[$type][$name]) makes $options[$type][$name] appear in MutatingScope::$moreSpecificTypes.

this part is not true due to

I tried to remove this line, but was not sure how to solve the failing tests.

I'll look into it again!:+1:

The linked lines are supposed to be just an optimization that we might be able to remove I think. (But it's a long time since I touched these parts last time).