as in they might remove the call to clearValidationProviderCache()

I don't see how that'd be different if this method was a public method in the BV API. The call in WF should be documented, and then we should trust maintainers to do their job correctly (which I have no doubt of). The only difference is that method is a bit more complex to invoke if it is not public, but as said I think that's an acceptable trade-off as is use case is limited. If anything, I'd prefer to first take this route, collect experiences with it and make it an official thing in BV 2.1 or so.

Platform interface class, that could be implemented by javax.validation.Validation

We cannot have any dependency from Bean Validation to WildFly.

My strong preference is to go for the private method for now. I don't like to add methods to the spec'ed BV API we're not totally confident about, as we can never ever change them again.

One thing I can see us doing is to remove the current caching scheme from the default provider resolver. And if people actually need to cache resolved providers, they'd have to plug in their own custom provider resolver (and would be in charge of clearing its internal state after usage).