Is DNSSEC that commonly broken or is systemd-resolved overzealous?

It's probably both. Overall, based on previous reports, I would lean towards the latter (systemd-resolved being too strict in some cases). However, according to DNSViz, the domains' configuration doesn't quite pass all the checks either.

I'm also not 100% sure about certain DNSSEC mechanisms, but here's my take:

savannah.gnu.org

It's a huge mess. Systemd-resolved correctly detects an issue with the domain... but incorrectly rejects it based on information that it shouldn't trust.

1. The gnu.org. zone has signatures, but its delegation from org. doesn't include any keys to validate them against, so the resolver is not supposed to even look at those signatures at all – they are no longer part of the chain of trust. However, systemd-resolved looks at them anyway.

2. The savannah.gnu.org. name exists in two places, and they don't agree with each other. This problem would go unnoticed without DNSSEC, but would always fail validation with DNSSEC. However, due to problem #1, it fails validation even though systemd-resolved is supposed to quietly ignore it.

More detail on #2:

The same nameservers are hosting both the signed parent zone gnu.org. and the unsigned child zone savannah.gnu.org.. The problem is that former lacks an actual NS delegation to the latter; instead it just has plain non-delegation records at this name.

Things only happen to work because both zones are hosted by the same nameservers, so at first, when you're querying for A or AAAA records at "savannah.gnu.org", the answer is automatically served from the unsigned child zone.

It's clear that it's the beginning of a separate zone because it has a SOA record. But the DNSSEC validator needs to know whether this zone should be signed or not, so it attempts to query for DS records (or lack thereof) and this time the response is always served from the parent zone.

An unsigned sub-zone is okay if the parent zone doesn't have any DS records for it, which it proves by returning a signed NSEC record in place of the answer; te NSEC "proof of non-existence" indicates all record types which are present or absent for this name.

So the parent "gnu.org" zone correctly claims that DS records for "savannah.gnu.org" don't exist... but it also claims that NS records don't exist, either, i.e. the name isn't delegated to a child zone at all. (Apparently there is an SSHFP record though...)

Since the validator has the original unsigned answer indicating that it came from a sub-zone, and a signed proof indicating that there is no delegation to a sub-zone, the validation must fail.

...But, as mentioned in #1, none of those checks should be done in the first place, because the parent-parent org. zone also proves that its delegation to gnu.org. is unsigned, which means any NSEC records coming from gnu.org are moot. Systemd-resolved shouldn't be looking at them – it should be treating the entire gnu.org zone as not having any DNSSEC.