We have had this debate when we made Hibernate Validator pass the Bean Validation TCK. Let me try and explain our position.

I think the spec itself describes the state of the correct behavior. If only in spirit.
The only framework causing trouble to date is Weld. We cannot reference a framework specific workaround in a spec. That's crossing the streams

We are left with one solution, make the Bean Validation implementors handle Weld (or their CDI implementation) proxies specifically. This is the approach the reference implementation (Hibernate Validator) has been following.
I would highly prefer if you added this specific workaround for Weld proxies in Apache Bean Validator. You can do it without compile nor runtime link to Weld. Here is a link to how we did it in HV. https://github.com/hibernate/hibernate-validator/blob/master/engine/src/main/java/org/hibernate/validator/internal/util/classhierarchy/Filters.java#L46
We also added this rule for the overriding of parameter constraints implied by the abusive annotation copy: https://github.com/hibernate/hibernate-validator/blob/master/engine/src/main/java/org/hibernate/validator/internal/metadata/aggregated/rule/OverridingMethodMustNotAlterParameterConstraints.java

We ended up with this approach as we thought it was the best solution for users: the rule is properly raising an exception if the user makes a mistake but we let Weld do weird things without complaining.

I have opened BVAL-491 to consider a SPI in the next version of the spec but that's not my preference as I mention in this issue.

BTW Jozef Hartinger, I am not following when you claim that you can't fix it. Last time I discussed this with Pete and all (back when we did BV 1.1), I remember that you guys planned to fix it in a future version. Can you explain why you cannot? Esp. on a CDI 2.0 timeframe?