There is an underlying limitation in that there is no way to access the value in the Set that caused the violation (see jakartaee/validation#194).

Initially, we used to create a ParameterErrors instance for arrays and collections, with the collection/array as the backing object, and the container + container index allowing you to access the value. It sort of worked for Set but there was no index and no way to access the actual value. There was an attempt to improve that in #31530 for Set and other (custom) container types, but it was based on an incomplete understanding of the available metadata, leading to #31746 and the subsequent change d7ce13c is what made it impossible to use a collection that is not indexed.

The subsequent change 8552e14 that you referenced further refined that so that collections/arrays are more correctly represented with ParameterValidationResult as directly validated method parameters (rather than with ParameterErrors for cascaded violations on an Object), so there is no longer a backing object to set, just the argument value. That did not change anything for sets though.

I think we could create ParameterValidationResult with the Set as the value that was validated, rather than the actual element, which we cannot access, but there would be no container and no container index. That would allow the error to be reported as before, but if there are multiple errors on the same Set there would be no way of telling which one is which. This wouldn't be anything new, but would simply restore what was possible in 6.1.2.