To me your proposal looks like the way to go if we want to have this feature in. With giving 1.0 interpolation precedence over EL evaluation, also backwards compat. issue should be solved.
* Is the benefit offered by this solution big enough to introduce a dependency to another API/JSR?
This is the major question, and I haven't quite made up my mind.
We don't really use types from the EL API in BV, so AFAICS the dependency would not be there in terms of a Maven dependency from the BV API to the EL API, right? That is, BV providers could handle it optionally and require it only if EL expressions are actually used, or?
In any case we're adding quite a lot just for the use case of the "inclusive" flag.
On a related note, WDYT about https://hibernate.onjira.com/browse/BVAL-339? I think if we add support for EL evaluation, it would make very much sense to allow for setting additional message parameters. At least we should add ConstraintValidatorContext#unwrap() to allow for BV providers adding proprietary means for doing so.