How to validate DNSSEC signatures - zone cuts?

Question

RFC 4035, section 5.3.1 lays out the rules for validating DNSSEC RRSIG records:

1. The RRSIG RR and the RRset MUST have the same owner name and the same class.
2. The RRSIG RR's Signer's Name field MUST be the name of the zone that contains the RRset.
3. The RRSIG RR's Type Covered field MUST equal the RRset's type.
4. The number of labels in the RRset owner name MUST be greater than or equal to the value in the RRSIG RR's Labels field.
5. The validator's notion of the current time MUST be less than or equal to the time listed in the RRSIG RR's Expiration field.
6. The validator's notion of the current time MUST be greater than or equal to the time listed in the RRSIG RR's Inception field.
7. The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST match the owner name, algorithm, and key tag for some DNSKEY RR in the zone's apex DNSKEY RRset.
8. The matching DNSKEY RR MUST be present in the zone's apex DNSKEY RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7) set.

(numbering added by me for reference).

Rules 1 and 3-6 are obvious how to check mechanically, but the remaining ones depend on identifying the zone to which the RRset belongs, for which no procedure is clearly spelled out. In particular, rule 2 is hiding a lot ofg complexity.

Consider for example a zone example.com with b.c.example.com delegated, and a.b.c.example.com defined in the latter. Then a signature for any RRset for a.b.c.example.com needs to have signer name b.c.example.com (and thereby be signed by a DNSKEY belonging to b.c.example.com), and so would any RRset for b.c.example.com itself (the zone apex) except for the DS delegation RRset from the parent zone, which need signer name example.com. Is there an official rigorous explanation of how this should work, and for how a verifying process should determine (prove) the zone cuts?

One might naively think, because of the hierarchical nature of DNS authority, it doesn't matter, and that it would be okay to just assume the the signer name is the name of the zone as long as it's a suffix of the RRset owner name - for example, that you could let example.com sign for a.b.c.example.com even if b.c.example.com is a delegation. However, that gets bad when you consider what happens at the root and TLD levels. For example, com should not be trusted to sign RRsets for a.b.c.example.com unless it has signed a proof that example.com is not delegated. This is because, while signing random forged descendant RRsets might easily go undetected (until there's something like CT for DNSSEC), signing proof of non-delegation could easily break the whole delegation if propagated, making the forgery higher-risk.