It's kind of the inverse robustness problem - lots of perfectly-well documented protocol features are not usable in practice since they break "lazy", but important, implementations. The SIP crowd will remember the endless discussions about MIME multipart.
In those cases, it would probably be wise to simply declare that a well-intentioned feature is no longer recommended for new implementations and possibly look for alternative options. (We seem to get into the circular arguments of "We need X", "use standard mechanism M to do X", "but none of the major implementations do M and are unlikely to in the foreseeable future", "but we cannot have two ways to do X and M is actually a better idea"; wait two years; repeat. Alternative: people develop a kludge that kind of works.)
The old, rarely-exercised, promotion-to-Draft-Standard step was supposed to catch this, but that process protocol path obviously was also rarely exercised.
Henning
And then for a counter example, also related to IPv6. The IPv6 specs
allows implementations to insert a variety of intermediate headers
between the IPv6 header and the transport packet, but many router
implementations just don't like that and slow down or drop packets if
such intermediate routers are present. A case where the spec is arguably
too permissive, or the implementations too strict.
-- Christian Huitema
