The spec indicates that updates are supposed to be atomic, and if they cannot be atomic, then they must be rolled back. If even that is difficult, then non-conformance must be documented.

What seems to happen in practice is that updates are usually non-atomic, rollback is never attempted and this non-conformance is often not documented. Return values seem up in the air, some return the records that were modified along with an error, others return no records (even though some were modified) and an error.

Going through the providers one by one:

• namesilo - ❌ Updates individual records, no rollback attempt, no documentation, returns modified records and error on failure
• cloudflare - ❌ Updates individual records, no rollback attempt, no documentation, returns nil and error on failure
• westcn - ❌ Updates individual records, no rollback attempt, no documentation, returns nil and error on failure. It's worth pointing out in this case that updates are not permitted, so they must delete first and replace the record, so if creating the new record fails, it can leave the zone in an unexpected state.
• inwx - ❌ Updates individual records, no rollback attempt, no documentation, returns nil and error on failure
• rfc2136 - ✅ Conforms, as one would expect
• huaweicloud - ❌ Updates individual records, no rollback attempt, no documentation, returns nil and error on failure
• simplydotcom - 🟨 Updates individual records, no rollback attempt, has documentation, returns nil and error on failure
• dynu - ❌ Updates individual records, no rollback attempt, no documentation, returns modified records and error on failure
• nanelo - 🟨 Doesn't implement RecordSetter
• domainnameshop - ❌ Updates individual records, no rollback attempt, no documentation, returns nil and error on failure
• ionos - ❌ Updates individual records, no rollback attempt, no documentation, returns nil and error on failure. From a quick glance, this one can be fixed easily, since they have methods to batch update records, they're just not used here for whatever reason. I don't use this provider nor did I do any deep digging, so there are probably reasons they opted not to go this route.
• ovh - 🟨 Updates individual records, no rollback attempt, has documentation, returns nil and error on failure
• scaleway - ❌ Updates individual records, no rollback attempt, no documentation, returns modified records and error on failure
• he - ❌ Updates individual records, no rollback attempt, no documentation, returns nil and error on failure
• gcore - ❌ Updates individual records, no rollback attempt, no documentation, returns nil and error on failure
• azure - ❌ Updates individual records, no rollback attempt, no documentation, returns nil and error on failure
• desec - ✅ Conforms!
• infomaniak - 🟨 Updates individual records, no rollback attempt, has documentation but it's confusing since it's the RecordSetter documentation but with some words changed and at a quick glance is easy to gloss over, returns nil and error on failure
• duckdns - ❌ Updates individual records, no rollback attempt, no documentation, returns nil and error on failure
• alidns - ❌ Updates individual records, no rollback attempt, no documentation, returns nil and error on failure

I skipped providers that haven't updated to 1.0.0(-beta) yet (since this behavior wasn't specified prior) and special cases like acmeproxy or acmedns.

I'm not trying to dunk on the authors of these implementations, I'd bet it's because these providers are missing bulk operation APIs. My point is that the current spec seems like it's not viable for implementers, causing the vast majority of them to be non-conformant. It's probably too late since 1.0 has stabilized, but it seems like RecordSetter should not make the promise of atomicity given the provider landscape.