I found a number of other similar discussions/issues about this general topic, but none of them are exactly about my specific use case so let's try a new discussion. :>

I'm trying to inform PHPStan that $rest is always a list<string> in this method:

class SomeController {
	#[Route('/some/route/:first/:rest+')]
	public function someRoute(string $first, array $rest): bool {
		return true;
	}
}

I'm mostly trying to avoid having to repeat @param list<string> everywhere, since it can always be inferred from the attribute. Unlike pretty much all the other issues I found, I only deal with primitives so missing out on IDE autocompletion is not a real concern. At most it might complain that you're passing implicit or "incompatible" types somewhere, like when using array_map(strtolower(...), $rest). But at least PHPStan would know what the actual type is and can still properly analyse the method.

1. Writing an ignore-errors extension for e.g. missingType.iterableValue is not a viable option for similar reasons, as PHPStan still wouldn't know the type so it'll still report an error on the same array_map() call. Not to mention that ignoring errors can really only lead to bugs, so I'm trying to avoid that as much as possible in the first place.
2. I also thought about generating stubs for every controller class but that seems pretty wasteful and maintenance-heavy.
3. Variadics unfortunately aren't an option either, as you can also define the route as :first(/:rest+) and that would require a ?list<string> type. Trying to represent this with a variadic is incorrect: it implies NULL can appear anywhere in the actual values, which is not the case.
4. I even tried messing with ExpressionTypeResolverExtension like a previous discussion we had, but in this case it's not actually an Expr so that's never going to work. The only real thing I can think of is using such an extension to change the type based on specific variable accesses, but PHPStan still wouldn't know the type at the start of the method so it'll still report missingType.iterableValue there.
5. There's also a PR that sounded interesting, but it looks like it still only changes the type at a call site and not inside the actual method itself.

Is there a realistic chance of an extension point being made available that allows me to do this one way or another? And if not, are there even any viable alternatives (besides writing @param list<string> of course)?