but if both A and B change I really only need the consumer to run once
If the consumer needs to run once, then the change of these two fields counts, to the consumer, as one event.
An event is defined as a reason to take action. If you only need to take action once, then by definition there was only one event.
The problem I run into is when I have consumers that care when any of a set of attributes change.
It seems like you're trying to provide solutions for all possible consumer use cases you can think of that you might want to have in the future, rather than focusing on what concrete use cases you have before you now. That's rather impossible to answer, especially by internet strangers who have no clue about your business context.
If your approach is based on what the consumer needs (i.e. the consumer dictates requirements, you don't dictate to the consumer), then you simply have to see what it is your consumer needs, and use the system that is appropriate for their needs.
If instead you are the one dictating, (i.e. you build the system the way you want, and the consumer will deal with the API you create for them), then implement it however you see fit - you are dictating the system requirements after all.
Good tip: don't try to immediately write an all-encompassing solution, unless that is concretely asked of you. A Swiss Army knife has many solutions, but each individual solution is inferior compared to a specialized tool. The Swiss Army corkscrew is not as good as a dedicated corkscrew tool. The Swiss Army knife is not as strong as a dedicated knife. And so on.
Trying to write an all-encompassing solution often comes from not wanting to have to rewrite parts of your application. But rather than being averse to change (because the possibility of change is inevitable), rather try to minimize the impact of when you do have to change something.
This is the main goal of clean coding principles. If you stick to them, even though it may cost more effort in the short run, it will greatly simplify any change you have to make in the future. And because of that, when you practice clean coding, you won't need to be change-averse anymore, and therefore don't have to tackle the all-encompassing solution.