It should be investigated whether the interface javax.validation.ValidatorContext could be re-defined as self-referential generic type as follows:
Provider-specific extensions of this interface (such as HibernateValidatorContext) then wouldn't have to re-define all of ValidatorContext's methods returning their own type (which they currently must do in order to allow for the method chaining pattern to work correctly).
Generally this is a breaking change, as existing implementations wouldn't compile with the proposed new version of the interface. But as it is intended to be implemented by BV providers only, this seems acceptable. API users would get a raw type warning if they have variables of type ValidatorContext. This should happen very rarely though, as ValidatorContext typically is only used in chained method calls (with a final getValidator() invocation) but not assigned to a variable.
Closing this; it would have been nice to have ValidatorContext defined in the suggested way from the get-go. But it seems not worth changing it now, as it only implies a small once-off effort for BV providers, whereas making the type a generic one now would potentially cause raw-type warnings to users.