From @kasperisager and @annethyme: Do we need to define in the ACT Rules Format what we mean by atomic?
Our take on it is that rules stop being atomic when splitting a rule further would cause duplication, e.g. by having to actively exclude cases caught by other rules from the applicability.

Proposed response:

The ACT Task Force has decided not to further define the term "atomic" in the ACT Rules Format. While there are differences of opinion, and discussions on the subject will likely continue, not having a stricter definition of atomic rules does not seem to prevent the implementation of the ACT Rules Format.

Further breakdown

Roughly speaking there seem to be two variations. Testers that look at the semantic role of components on the page, and testers that further distinguish which native element is used to provide this semantic role.

The advantage of rules based on semantic roles require fewer conditionals. For example, a rule about button elements needs to exclude button elements that have a role attribute that change the semantic role to something else. A rule that is about elements with the semantic role of button do not need this conditional logic.

The advantage of rules based on native elements rather than semantic roles is that the remediation advise can be inferred from the rule. The remediation advise for an input button includes setting the value="" attribute, whereas for a div with role="button", the value attribute should not be included in the remediation advise. Having rules written at this level allows a 1-to-1 mapping from the rule to its remediation.

It seems to me that both approaches have their merits, and that the choice between one and the other will likely be based on how remediation is going to be approached. For the sake of consistency, the W3C will likely have to decide which direction they would like to go when publishing rules. But I don't think this is something that should be defined as part of the ACT Rules Format. There are good reasons for both approaches, and enforcing one over the other could make adoption more problematic.

Proposed response acceptable, but I'm sure discussion will continue in future versions of the document.