But that's not what he actually wrote, and I can easily imagine a future where this "law" starts to be quoted in contexts where it doesn't turn out to apply.
1. A lot of code 2. The ability to test all of their dependencies code
And so the people making the changes can detect all of the breakages. If it was possible for me to run the CI for every system on GitHub that depended on the library, it might be more obvious, but usually the cost of these unintentional breakages is borne by users not maintainers.
The law applies to anyone who maintains a widely used library, whether that's good, Django, or std::.
And note that many more people in this thread are calling the law "obvious", than thinking it's not true. That should give you some pause.
But the "law" is not literally true, so to make it useful you have to mentally add some reservation: "no, of course I don't mean that someone will be depending on a detail like _that_".
The trouble then is that it doesn't work usefully as a piece of advice: if you're not already experienced enough to know where to draw the line, it doesn't help you get any more accurate.
It's like saying "however big you think X is, it's bigger than you thought".
But maybe I'm wrong about what you believe. Do you actually think the "law" as stated is literally true (without using a quibble like "well, there's no upper bound on what we mean by 'sufficient'")?
Is there intended to be an implicit limit of "all the people in the world who might plausibly use this API"? Then I'm sure the law is false.
If there isn't intended to be such a limit, then the law is unfalsifiable and not useful as a guide to activity.
I think this purported law comes from the sort of advice you can end up giving when you notice that many young programmers err too much in the direction of X, so you make an exaggerated statement in the direction of not-X to correct them. This can be distinctly unhelpful in the long run.