Fair enough, but I would not expect so many @URL constraints used within the same model.

It's something we can't really know. But imagine a situation where the new reg-exp indeed is an issue and you want to go back to the previous behavior. As a user, what would you prefer: a) search all @URL occurrences in your code base and re-build the application or b) just change a property in validation.xml ?

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

That's a problem, though. Why introduce a new attribute if there are already existing (and even more concise) means of achieving the same? I'm no fan of this kind of choices. There should be one way to achieve a certain goal, and it should be as easy and intuitive as possible to go that way. Choice of this sort only add complexity and make the library harder to use in the end.

Also, it is just an option for the performance conscious.

But everyone wants the best performance they can get, right. Thus it must not be cumbersome to turn the perf knob, specifically it should not be required to turn the knob several times, but once and be done with it.

That's a bit too opaque for my taste.

Rembember that this is a performance improvement which should have no functional impact whatsoever. Ideally it would be fully transparent (i.e. on by default without any changes), but as there are concerns about backwards compatibility, we probably shouldn't do that. But if that's not an option, the more transparent and hazzle-free it can be enabled (and disabled), the better.