Issue #35213 added some very helpful features to path patterns that were supported by AntPathRequestMatcher, which is being removed in Spring 7. Thank you. But, the commit comments in d3c1e67 say that the enhancements come with the restriction that "/{*path}/{folder}/file.txt" "/**/{folder:[a-z]+}/file.txt" are invalid because only a literal pattern is allowed right after multiple segments path elements."

It doesn't explicitly say so, but I assume that something like "/**/*.html" or "/**/files/*-image/*" are also invalid because the portion after the /**/ isn't literal. Is that correct? If so, that will create problems with us migrating from AntPathRequestMatcher to PathPatternRequestMatcher, because we have quite a few Ant patterns of the form "/**/*.\<extension>" such as "/**/*.html", "/**/*.js" and so forth.

It would be very very helpful if path patterns were expanded to allow at least a final path segment involving *, and ideally would allow /** or /{*path} to be followed by any combination of path segments that use only the following expression types in each path segment: literals, ?, *, {spring} and {spring:}. That is, the multi-segment match expression can be followed by any number of other path segment expressions except ** and {*path}. But if that is too much of an ask, then at least supporting our commonly used expressions such as /**/*.js would be extremely helpful, and it would be very helpful if this was also backported to 6.2, just like #35213 was, as it will allow us to do preliminary version-7 migration work while still using version 6.

It seems to me that it should be possible to do this without losing efficiency, because none of those expression types can match multiple path segments, and it would still be quick to determine exactly how many path segments would match against the /** part of the expression vs. against the rest of the expression, by counting path separators after the multi-segment expression.

That would leave only one kind of Ant expression in our codebase that path patterns could not handle: things like "/**/rpc/**". I don't want to add complexity to my main ask here by adding that to my request, since we only have a few uses of that vs. many of the /**/*.\<extension> format, but I thought I'd mention that there is still that gap for us. At least for literal values, which is all we have these cases, the implementation reduces to seeing whether the path contains "/rpc/".