I see this from a different perspective. The developer using the API or tool has a valid expectation that their software should continue to work as-is for years even as outside changes are made to the underlying tools, libraries and features. The flaw here is instead, in my opinion, a willingness on the providers of these tools and libraries to pull the rug out quite frequently on their end users.

If there is a security risk, you can mitigate that by redirecting your users who still use the feature to what I'll call a "diversion" along with a warning that they will no longer receive updates and to consider the feature obsolete. Perhaps with a popup or console blurb that warns the user of the problem, this way the end user developers eventually do have to fix it because users will bother them about the issue.

I understand it creates clutter that maintainers would like to avoid, but the alternative is constant rug pulling that undermines productivity and the usefulness of your tool or library. You created your software or tool to help others whether for financial gain, altruism or ego boosting. I think you forget that when you decide to throw your hands in the air and rug pull. It is irresponsible and lazy. You are shirking your duties onto others.

We need a new system, process or design pattern to help alleviate this issue in our industry. Because end user developers and system or library developers are constantly butting heads over this. There is a strong smell here that needs to be resolved. It is a problem in search of a solution. I think we can potentially engineer our way out of this.

For example, if you developed software for the first Google Android phone, it no longer works on the latest phone. It should. Why wouldn't it? I wrote a piano app that no longer works, it would require a full rewrite and recompile. And, this isn't just between an ancient version and a new version of the phone. Just one SDK update and they've suddenly changed all of the interface names, function arguments, etc. Just because they thought a name sounded cooler or clearer. This is irresponsible design.

Microsoft does a great job with their APIs being backwards compatible as much as possible. But, the cost is having to carry a massive history of APIs and tools they can never truly sunset. If you develop something for the first DirectX SDK it still works on the latest release. Because, they number their interface names. I'm not saying this is the ultimate solution, but it is one way to address the problem. But, it has problems of its own.

I'd like to see a large effort to address this, we keep avoiding it as an industry.