So one would have to specify the constraint like this when wishing to use the new reg-exp, right:

@URL(regexp=RFC_3987_REGEXP, regexpOnly=true)

Correct.

I don't know, but this really looks too verbose to me. As a user, I'd then rather use @Pattern

Sure. No one would be stopping you doing this. You have the choice really. It would be a matter of taste I guess.

Switching between current and new behavior is something I'd want to do once for all @URL constraints, not for each single constraint instance.

Fair enough, but I would not expect so many @URL constraints used within the same model. IMO the effort too configure explicitly is not too high. Also, it is just an option for the performance conscious. If I were to write a URL shortening application and I do URL parsing/validating all the time, performance might become an issue, but I don't think it is so important as part of a average domain model.

Offer a global configuration property for changing the validation behavior from current to the new reg-exp based approach

That's a bit too opaque for my taste. Also it would requite to at least provide a validation.xml as well (or in some other way interact with the BV bootstrapping).

Offer a new constraint, e.g. @Url2, @Rfc3987Url etc.

I like this better than the first suggestion, but I think I still favor the modification of the existing constraint.