The bean validation specification mentions the following

Clients call Configuration.buildValidatorFactory() to retrieve the initialized ValidatorFactory instance. It is legal to invoke buildValidatorFactory() several times, e.g. in order to retrieve several ValidatorFactory instances with a slightly different configuration (see Using Configuration to create several validator factories).

to indicate that a Configuration can be used to create several ValidatorFactories, but hibernate validation violates this aspect when it comes to MessageInterpolator.

I've attached a small maven project to implicate the issue. One can use

mvn clean verify -Phibernate5
mvn clean verify -Phibernate6
mvn clean verify -Phibernate61
mvn clean verify -Phibernate7

on the attached project to test the different versions (5.4.3.Final, 6.0.19.Final, 6.1.4.Final, and 7.0.0.Alpha1 respectively)

My investigation as to a possible RCA found that this is likely a regression from the change introduced in HV-1131 Closed , at HV-1131 code change, which equates to once getMessageInterpolator() is invoked, the first return is locked-in and all future invocations will always return the same value, even if messageInterpolator() is utilized.

As a workaround to have hibernate respect the bean validation specification, one must reflect on the Configuration and set the messageInterpolator field to null before doing any operation that performs getMessageInterpolator(), such as buildValidatorFactory() (which to honestly state is a rather dirty workaround)
I also cannot state that such a workaround will work long-term (such as with the module system of Java 9+)