> What if we intentionally made deprecated functions return the wrong result … sometimes? Every time it intentionally returns the wrong result, it logs the deprecation warning.1

What if we found that a highway overpass construction material was suboptimal, and we want people to use superior materials, so, every now and then, we send a chunk of concrete plummeting down to the ground, to kill a motorist?

Thanks to deprecating like we mean it, they're going to replace that overpass sooner than they would otherwise. You'll thank me later.

From the https://sethmlarson.dev/deprecations-via-warnings-dont-work-... that the post opens with:

> This API was emitting warnings for over 3 years in a top-3 Python package by downloads urging libraries and users to stop using the API and that was not enough. We still received feedback from users that this removal was unexpected and was breaking dependent libraries.

Entirely predictable.

Even many of those who saw the deprecation logging, and bothered to make a conscious decision, didn't think you'd actually break the API.

> We ended up adding the APIs back and creating a hurried release to fix the issue.

Entirely predictable.

Save yourself some anguish, and don't break API unnecessarily. Treat it like a guarantee, as much as possible.

If it's a real problem for ongoing development, consider using SemVer and multiple versions, like the linked article suggests. (With the deprecated branch getting minimal maintenance: maybe only select bug fixes, or only critical security fixes, maybe with a sunset on even those, and a deprecation warning for the entire library when it's no longer supported.)