What Can You Put in a Refrigerator?

You can perhaps (but my confidence is low) avoid violating the first part of the law if you're a TCP stack implementor, say. There just aren't that many such implementations nowadays and they're generally done by people who know what they're doing. But applying Postel's law to something like programming language implementations, where the "implementors" who would need to obey the first part are all the people writing programs in the language, pretty much guarantees violations of that first part. For any given programming language anyone cares about in practice, the number of people who know the spec for it well enough to only write code that conforms to that spec, even on their first try, is _tiny_ compared to the number of people writing programs in the language.

At that point your only option is to accept that the first part is going to be violated, and badly. Only once you have internalized that understanding can you have a constructive conversation about whether you want to do the second part and to what extent. The answers here will vary, of course.

Your example is modeling a real dog better than the sample you started with, but... what computer programs acts on a real, live dog, directly? Computer programs pretty much never interact directly with external reality, only with other software -- interfaces to hardware and other software systems. So software needs to be smart and clean about dealing with the actual interfaces. It's important to understand how reality will interact with the interfaces, of course, but relationships there are often irrelevant or misleading to designing the software.

So all of these poor students, when actually charged with designing a program dealing with, say cashiers, store managers, purchases, reports, etc., start off "well, cashiers and store managers are people, and actually both employees... I guess we need a company object in here", etc.. This almost always leads them into a mess, because they get lost in here before they even learn properly what the goals of their system are. E.g., this program just needs to run on the store managers PC, pull data from a dir full of files from the POS, and generate reports (in which the cashier is just another column value).

If they started OO as "modeling reality", just writing a program that does what's needed feels like cheating ("TODO: not really capturing the OO relationships here! rework for v2") -- and that's a bad thing.