The activiti:candidateGroup is just a shorthand for the verbose BPMN2.0 way of defining candidates for a user-task. In this syntax, no AND/OR semantics are present, so it's unlikely this attribute will be adjusted to the use-case you describe.
An approach you *could* take is to use a BPMNParseListener to alter the values of the candidates on the user-taks and further down in the implementation, use an altered version of the task-query that is used… However, this will require some digging into the activiti-code.
Another approach would be to have "special" groups, e.g. of a candidate-expression: "group(group1&group2), group(group3)".
By default, the expression will resolve to 2 groups: "group1&group2" and "group3". In activiti, this means part of "group1&group2" or "group3". Now, if you alter the identity-management to return these "special" groups as "groups a user belongs to", activiti will show the task as claimable by someone in group1 and group2.
Offcourse, this means a user gets a lot of extra special groups, when part of a lot of "normal" groups. So some kind or "restricting" mechanism should be created to only make special groups for well-known groups which are likely to be used in "AND" semantics…