I guess you saw it already yourself, but just in case: seems you found a case in which we miss to narrow a constant arrays optional offsets :-)

https://phpstan.org/r/6286a642-020a-4e53-b713-72994a0bbcad

Yes, was creating a similar example in parallel (https://phpstan.org/r/d6b8098a-282b-47cd-be91-38e42401d1eb) :) let's fix that first..

This pull request has been marked as ready for review.

currently: https://phpstan.org/r/a1181543-1503-4108-bcf4-ee8e13abda66

so most of it are things like

Expected type array{0: string, 1?: string}, actual: non-empty-list

not sure if this PR even adds much value..
some max limits at least I guess hmm, could still be useful potentially?

oh interesting, the 3 failing tests show that the narrower type can cause new offsetAccess.notFound errors to appear:

• https://github.com/phpstan/phpstan-src/actions/runs/13833502116/job/38703310885?pr=3708
• https://github.com/phpstan/phpstan-src/actions/runs/13833502116/job/38703311456?pr=3708
• https://github.com/phpstan/phpstan-src/actions/runs/13833502116/job/38703311898?pr=3708 -> https://github.com/doctrine/collections/blob/2790cb57e6510e4404873bdca6688e447550d720/src/Expr/ClosureExpressionVisitor.php#L44

which I think is expected and fine.

What to do about this one? Is it OK or e.g. bleeding edge toggle maybe?

The problem with this one is that it promotes errors that would previously be only reported with reportPossiblyNonexistentGeneralArrayOffset: true to be always reported.

Does this have an actual benefit? Isn't non-empty-list<string> enough?

I was also not sure. If in doubt, maybe it's better not do this. At least the preparation work for this uncovered other count related improvements 😊