"As a courtesy to implementors, it is hereby noted that the complete
set of such previously published RR types that contain embedded
domain names, and whose DNSSEC canonical form therefore involves
downcasing according to the DNS rules for character comparisons,
consists of the RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV,
DNAME, and A6."

Almost exactly the same list. One HINFO too much is no issue,
but if this actually should be TXT it's a real typo.

neither TXT nor HINFO contain domain names in RDATA, so it's a bug in both
RFC 3597 and 4034, although one that doesn't hurt. One could also argue that the list lacks NSAP-PTR, but then that's as obsolete as MD ans MF.

These groups are then added together with at least 32-bit precision,
retaining any carry bits.
The carry bits are then added to the result, and finally, only the lower
16 bits of the result are used as the key tag. Note that this means any
carries generated during the addition of the carry bits are ignored.
This, in turn, means that the keytag calculation is often the same as
reduction modulo 65535, but not always.

Notes:

Errata 2681 already proposes a fix to Appendix B, however the proposed fix is not quite clear. The first part of the corrected text is from 2681.

Its worth pointing this out because a naive analysis says in fact the keytag is exactly the same as reduction modulo 65535, and this has already wasted a fair amount of time.

It is also worth pointing out, perhaps, that this is a poor choice of algorithm for this particular application as it interacts badly with the properties of keys.

For a
DNSKEY RR with algorithm 1, the key tag is defined to be the most
significant 16 bits of the least significant 24 bits in the public
key modulus (in other words, the 4th to last and 3rd to last octets
of the public key modulus).

It should say:

For a
DNSKEY RR with algorithm 1, the key tag is defined to be the most
significant 16 bits of the least significant 24 bits in the public
key modulus (in other words, the 3rd to last and 2nd to last octets
of the public key modulus).

The key tag is the same for all DNSKEY algorithm types except
algorithm 1 (please see Appendix B.1 for the definition of the key
tag for algorithm 1). The key tag algorithm is the sum of the wire
format of the DNSKEY RDATA broken into 2 octet groups. First, the
RDATA (in wire format) is treated as a series of 2 octet groups.
These groups are then added together, ignoring any carry bits.

It should say:

The key tag is the same for all DNSKEY algorithm types except
algorithm 1 (please see Appendix B.1 for the definition of the key
tag for algorithm 1). The key tag algorithm is the sum of the wire
format of the DNSKEY RDATA broken into 2 octet groups. First, the
RDATA (in wire format) is treated as a series of 2 octet groups.
These groups are then added together with at least 32-bit precision,
retaining any carry bits. The carry bits are then added to the result,
and finally, only the lower 16 bits of the result are used as the key
tag.

Notes:

This change comes from the example implementation. The accumulator, ac, is required ("assumed") to be 32-bits or larger, and the carry bits are added to the accumulator before returning:

The value of the Labels field MUST NOT count either the null (root)
label that terminates the owner name or the wildcard label (if
present).

It should say:

The value of the Labels field MUST NOT count either the null (root)
label that terminates the owner name or the leftmost label if
it is a wildcard.

Notes:

In RFC 4035, section 2.2, describing the same count uses this: ... "and not counting the leftmost label if it is a wildcard" to omit the leading wildcard label. (In 4034, the wildcard label is defined as "*" earlier in the same problematic section.)

The text in 4034 could be confused with having to count "wildcard labels" in the middle of a name, such as in name.*.tld. The reason for suggesting this errata is for compliance considerations.
--VERIFIER NOTES--
All wildcard labels start with * in the leftmost label. No other kind of wildcard label exists.

From RFC 1034:

4.3.3. Wildcards

In the previous algorithm, special treatment was given to RRs with owner
names starting with the label "*".