There's one aspect of these deprecations of functionality in widely-used tools and agents that is often overlooked. The very premise of the deprecation and rem

There's one aspect of these deprecations of functionality in widely-used tools and agents that is often overlooked. The very premise of the deprecation and removal is that any code-base that uses that functionality is being constantly maintained and can be updated. That is a major misunderstanding that in the 'web' development world has become the norm due to 'DevOps', Continuous Integration, Continuous Testing. There are many codebases out there that achieved their objectives, are finished, and are effectively unmaintained since they work as designed. When the functionality they use is removed they fail and the end-user loses out. This is always going to be a major problem for historians, historical web-site and code archives that have active code (not just passive HTML/CSS). The problem we have is that with deprecations and removals of functionality that was previously recommended and/or 'best practice' our ability to maintain digital history is being chipped away. Historically, we've already lost the ability to easily use Adobe Flash (good from a security perspective but not so much from a historical perspective) and Java applets (still many 'enterprise' devices rely on them) and all those web-sites that relied on Internet Explorer specific features. For each codebase we now have to figure out which specific tooling and versions are required and try to re-acquire them. Not excessively difficult for open-source tooling but challenging for closed-source and proprietary tooling. Another related issue building up is the switch to 64-bit and the subsequent bit-rot of 32-bit support. It feels like the horizon to failure of a completed "web" codebase is less than 10 years.