I think the reasoning at the time was that executable-validation and friends are not used at all by the Bean Validation Provider. They are only of interest for the integration technology that will run the interception.
Considering that, we likely decided that bootstrapping ValidatorFactory with that info is equivalent to a noop and thus not programmatic API was needed.

It boils down to who is using the programmatic API for the BV instance used to validate executables? If that's the DI container, it would know the programmatic calls it would want to call and thus already know of the executable-validation settings. If it delegates to a user that build, then:

• either yes we could add it to Configuration but we would also need for a way to extract that info
• we let the bootstrap code provide its own Configuration instance to the user code and know what it calls

I'm still unclear on the use case at the end of the day.

PS: that makes me think, can we validate parameters and return value of a lambda? Can we add constraints on a lambda declaration?

collection.foreach( @Email e -> System.out::println );