Let's take a small step back.
Today a user can enforce a specific BV provider by setting it in the XML file. If not is selected, then Validation.buildDefaultValidatorFactory() pick one "randomly".
When booting BV programmatically, you can also specify which provider you want via Validation.byProvider(HibernateValidatorConfiguration.class).
...

This is actually a good point. On the other hand, is adding the extension jar of a certain provider to your container/app not equivalent to Validation.byProvider(ProviderClassOfProviderWhoseExtensionIAdded.class). So in the case of HV. If you are adding hibernate-validator-cdi you are adding the ValidatorFactory and Validator of Hibernate Validator. IMO it does not make sense to add hibernate-validator-cdi and then bootstrap a different provider. If you want another provider you should add its cdi extension.

I can see where you are coming from with your Valiation API point of view, but I think from a CDI point of view my argument holds as well.

if we want a qualifier, why not have a BV generic one @FromProvider(HibernateValidatorConfiguration.class). The only drawback I see is that this qualifier belongs in Bean Validation and that require us to depend on CDI which might be a no go after the discussions with the JavaFX team.

-1 for adding a dependency to CDI

I find it a bit annoying as a user when I define a provider in the XML descriptor but I also have to use a qualifier in my injection points.

Why? It is a different programming model. XML is great for standalone apps, but once I work with a CDI container other abstractions and APIs come into play. In fact as a pure CDI user I would even expect that I have to use a qualifier and would be confused by the need of fiddling w/ valiation.xml.

What happens for an existing BV 1.0 application today? AFAIK, injection of the "default" BV provider is done. I don't think we can break that behavior.

I don't think we do (unless of course they always added a second BV provider to their app which was different to the one provided by the container and happens to implement Extension. Very unlikely.