According to the RecordSetter.SetRecords documentation, implementations are required to ensure that for any (name, type) pair in the input, those are the only records (of that kind) present in the resulting zone.

For any (name, type) pair in the input, SetRecords ensures that the only records in the output zone with that (name, type) pair are those that were provided in the input.
In RFC 9499 terms, SetRecords appends, modifies, or deletes records in the zone so that for each RRset in the input, the records provided in the input are the only members of their RRset in the output zone.

If I'm not mistaken, Caddy (via certmagic) is the main consumer of this library. In its typical flow, when provisioning ECH, it usually calls SetRecords with a single record, and doesn't check beforehand (via GetRecords) for any existing records of the same name and type.

In the case of HTTPS with ECH, if someone tries to cover common scenarios for different versions of HTTP (2, 1.1, 3) with records addressing that, the implementation which follows the documentation (above cited) would make a mess.

For example, the ovh implementation takes care of deletion. Most other implementations don't.

This seems to work fine, so far, with most current provider implementations. I wonder if this discrepancy could lead to bugs or interoperability issues in less typical scenarios. Regarding this, what would be the guideline for future implementations?