Don't make it return a different result.

Instead, if you must, add a sleep within the function for 1 ms in the first release, 2 ms in the second release, and so on. But maybe just fix the tooling instead to make deprecations actually visible.

I get the intention but it's a bad idea, same with the article

if people are meant to depend on your endpoints, they need to be able to depend on all of them

you will always have ppl who don't respond to deprecation notices, the best you can do is give them reliable information on what to expect -- if they hide the warnings and forget, that's their business

but intentionally making problems without indication that its intentional results in everyone (including your own team) being frustrated and doing more work

you cannot force ppl to update their code and trying to agitate them into doing it only serves to erode confidence in the product, it doesn't make the point ppl think it makes, even if the court of public opinion sides with you

cover your bases and make a good faith effort to notify and then deal with the inevitable commentary, there will always be some who miss the call to update

this actually seems like an reasonable technical solution to the non-technical problem that causes deprecations to be ignored in the first place

Degrading performance exponentially (1ms, 2ms, 4ms, 8ms...) WILL create a 'business need', without directly breaking critical functions. Without this degradation, there is no reason to remove the deprecated code, from a business perspective.

It is sometimes a tooling issue, but far more often it's a "few teams have a discipline of squashing all toolchain warnings" issue.