Systemd catches up with bind events

Eh, I'm unconvinced. IPv4 did that with Class E addresses, back when classful networking was still a thing. Nowadays, classes are otherwise dead, we're running short of addresses, and Class E (now known as 240.0.0.0/4) is still "reserved for future expansion" - because everyone hard-coded it as invalid, sometimes even at the hardware level. So you can't use 240/4 without losing backwards compatibility. But if you're going to do a compatibility break anyway, you're far better off switching to IPv6 altogether, as it gives you far more addresses to play with and is generally less of a hassle to administer (for example, it lacks NAT). So those ~268 million IPv4 addresses will likely never be publicly routable.

Perhaps the RFCs of the time could have been written with greater care, but the trouble is that at the time (see RFC 988), they were in the process of designating class D (224.0.0.0/4) as multicast. They didn't know what class E would be used for, so they couldn't just say "treat class E as if it were unicast, unless a later standard says otherwise." For all they knew at the time, they would later want to use class E for some even weirder thing, and unicast processing would have been inappropriate or even harmful. So they just left it as "reserved," and the people who had to actually make the silicon and software decided that "reserved" meant "invalid." IMHO, they didn't really have much of a choice.

In short: From userspace's perspective, "reserved for future expansion" means "I don't know what this value represents, so if the kernel hands it to me, the only not-wrong thing I can possibly do is crash." In some contexts, ignoring the value *might* be not-wrong, but it's hard for userspace to predict that in advance. Regardless, the kernel cannot rely on userspace taking any particular interpretation, because as Linus has previously said, they don't break userspace, even where userspace is wrong.

So much this. A kernel config option which causes random, undocumented, events to appear, both for existing devices and for 'nonsense' devices. Correctly formatted messages (e.g. not fuzzing), but with types that are never used for real devices.

Chaos engineering can be quite useful.