There are some weirdness with that. I suppose you want the group to be applied to all parameters and the return value. Correct?

@ValidationGroup(Update.class)
@NotNull
String provideResults(@Valid Address address, @Email String email);

This is weird for several reasons, should the @Email and @NotNull be ignored because they don't list the Update group? That would be logical but very annoying to have to duplicate the group.

In essence, a group for a method validation is useful for the params or return values that are @Valid in the first place. Is it that common that you want to validate the same group for all @Valid parameters on a method that it warrants a @ValidationGroup like factorisation?

I think we did not add something like @ValidationGroup initially because the direct constraints (i.e @NotNull etc) on parameters never need grouping (maybe rarely).

Can you come and push your use case more with some concrete example to challenge what I said?

Another point, the inteceptor technology is the right place to let the user override the group that needs to be executed (like Spring has done). But it reaches the issues I am describing above on the direct constraints.
In CDI we decided that the mere fact that a method hosts constraints is a flag to require interception, which I think is better but that's ergonomics).