Previously committed zone failed with semantic checks at startup

We're running knot daemon version 2.9.5 and recently found it is possible to commit changes to a zone that are accepted and saved to file, but when the knot daemon restarts are rejected due to failure of semantic-checks irrespective of whether they are turned on or off for the zone.

Steps to reproduce

# First add an A record
knotc zone-begin zone
knotc zone-set zone zone.com. 600 A 1.2.3.4
knotc zone-commit zone

# Some time later, add a CNAME record but fail to delete the A record
knotc zone-begin zone
knotc zone-set zone zone.com. 600 CNAME destination.com.
knotc zone-commit zone

The second zone-commit succeeds, and knot begins to serve the CNAME record. The zone is committed to disk with both records present.

# Some time later, restart the knot daemon
systemctl restart knot

The zone now rails to load because the A and CNAME records conflict: error: [zone.com.] zone loader, failed to load zone, file '/var/lib/knot/zone.com.zone' (semantic check)

It makes no difference is semantic checks are enabled or disabled for the zone, if there are conflicting A and CNAME records the zone fails to load.

Expected behaviour

At a minimum, the daemon should not commit a configuration that it will fail to load on restart for the running configuration.

To me, it would make sense that if semantic checks are disabled the commit should succeed, and if checks are enabled then it should fail. However, I understand there are subtleties to the definition of "enabled" here.

Configuration

Knot daemon 2.9.5

I have tried this with both semantic checks enabled and disabled in the zone template configuration, which we have configured as:

template:
- id: default
  storage: /var/lib/knot
  file: "%s.zone"
  acl: [all-trust]
  serial-policy: increment
  zonefile-load: difference-no-serial
  # settings semantic-checks to on or off makes no difference to this bug
  semantic-checks:  off