Part of my role as a software engineer (and formerly a sysadmin) is that I need to read - and understand standards. As Ben Eater said once in his channel "standards trade clarity for specificity". This has many consequences - some of which we know as people implementing the standard incorrectly due to the lack of clarity (I've made this mistake plenty!). But I think this strive for accuracy ends up creating some unintended social outcomes.
See over time I've noticed that there is often a disconnect between the standard and how it's used. Maybe a law already exists for this, but I always say there is a divide between "the standard as intended" and "the standard as used".
LDAP is a great example of this, especially as something I've worked on for so long.
RFC 4511 defines the capabilities of LDAP, itself being a derivative of X500 DAP. LDAP defines
many operations - searches, updates, binding (authentication), extended operations, even the ability
to return referrals so that a query can be redirected. Extended operations allow the protocol to be
customised. Controls allow extra information to be returned in parallel to other operations. Searches
can request different sort and match orderings - you want to look up alphabetically with case sensitivity
or not? Even things like tagged attributes so you can have a name in multiple languages.
So what was the intent? The standard tells us what the operations are but not what the vision for them was.
The goal was a global, federated/trusted directory allowing multiple organisations to interoperate and even authenticate users across organisational boundaries. Consider logging into your workplace computer with a hardware security token that your government issued that identified you. That same token then lets you login to your email hosted by "I can't believe it's not google". One identity and method to authenticate you, all shared and trusted.
All of the parts presented become a part of this. But that intent isn't clear from the standard.
So despite all of the capability that RFC 4511 provides, what is actually used?
search and bind. In some edge cases you may see modify/create but not often. Certainly you
don't see LDAP being a global catalog of identities. Every organisation ends up running their own
small LDAP silo in isolation to everyone else, and most authentication today doesn't even go via
LDAP, opting for things like OAuth2 (another example of a misused standard).
That's the crux of this - despite the intent of the standard authors, the way that the standard is used is always different. Maybe it's a subset. Maybe it's completely orthogonal to the intent. Maybe things are added that betray the intent of the standard. But it is this disconnect that often leads to confusion and friction between standards authors, implementors, and users.
When viewed through this lens, so many challenges of modern technology start to fall into place.
Webauthn originally was designed to support security tokens (yubikeys) but was "used" to allow software password managers that violated the assumptions that existed. The standard provides tools to allow helping users find what credentials they could enrol, but when used by implementors ends up locking people out or denying them consent and choice of how they authenticate. Even within all the capabilities of Webauthn, there are only a few narrow paths within the standard that create good user experiences today.
OAuth2 exists to allow a service (client) to authorise a token that can be used on behalf of a user to access something (resource server). But more often than not, what the user is authorising to is the service itself, and the token never goes anywhere. OAuth2 is often (mis)used for "authentication" to linux machines despite the user experience being so horrible.
Honestly I could keep going - but all around us are the standards as (mis)used, despite their intent.
I guess if all you have is unclear standards, everything looks like a nail.