Your definition of broken is a little off. I would think the broken implementation is the one that misunderstood the definition. "reserved" as i have been enlightened privately has been clearly defined at IETF as:
a) Must be set to zero on transmission
b) Should be ignored upon reception.
A citation here (from anyone) would be really helpful. This is also my understanding, but I have no idea why I think so, and would prefer to continue the discussion knowing whether we've actually written this down, or whether this is a commonly held belief resulting from being conservative in what you send and liberal in what you accept.
If we set our time machine for the year 1981 and look at the text in RFC 791 describing the bits in the TOS byte, the picture shows bits 6 and 7 holding the value 0, while the text says "Bit 6-7: Reserved for Future Use" without further discussion.
So this doesn't help.
However, I don't see any way to reserve fields for future backward compatible use without requiring them to be set to a predictable value (i.e., zero) upon transmission and ignoring their contents upon reception. Obviously setting the field to a random value precludes adding new values with new meanings, since non-zero values could then be set by implementations that aren't aware of the new functionality. Requiring the fields to have a certain value upon reception makes "future use" of the field impossible, as implementations would then have to be upgraded across the board first, which is hard to do with a few hundred million systems deployed.