I think there are two things at play, Hibernate Validator and its message interpolation/resolution via ValidationMessages.properties as specified by the Bean Validation spec and the interpolation of Spring MVC using messages.properties.

The Spring integration (most likely, I don't know the code) calls first the Validator validation routine and then resolves the resulting error messages (if any) against its messages.properties.

Note also, that Bean Validation uses the curly braces ('{', '}') for message keys and variables. So the default message for @NotEmpty is really {org.hibernate.validator.constraints.NotEmpty.message}. Using this default, the resolution will occur within the Validator bundles. It works for myMessageKey (or in fact probably also for org.hibernate.validator.constraints.NotEmpty.message), since in this case Validator won't do any interpolation and the message is passed as is to Spring MVC message interpolation.

To make your use case work, the message interpolation as part of Bean Validation needs to be prevented. There is already a possible solution for this. Bean Validation defines the MessageInterpolator interface to plug in custom interpolators. You could just provide (at bootstrap) a no-op interpolator which always returns the non interpolated string. Of course the key in messages.properties would need to be {org.hibernate.validator.constraints.NotEmpty.message}.

The question is whether it would make sense for Validator to provide such a no-op message interpolator or not? One could also imagine to provide a configuration property org.hibernate.validator.skip_message_interpolation to make configuration potentially a bit easier.

I am atm a bit undecided whether this is worth doing from a Validator specific perspective or whether it is really up to the user to provide such a message interpolator. Also the for Spring integration code could be changed to allow this option.