A few missing tidbits

Your upload wasn't overwritten. It is still pending approval. And version tracking ensures that when it eventually is, all tracking copes fine. So I find that mischaracterization a tad unhelpful. I uploaded a targeted fix to make sure that we can make it available to people as fast as possible. It is true that this did not raise to an emergency point release.

As the person who opened up stable to more fixes years back, it was always done with an assumption that there is a minimal risk of regressions. This has always been the stable policy. So we need to own up when we do cause one - and any security update that causes a regression is also followed up on. I think here there is a question what the policy should be wrt such a central component - and a lack of a pre-point release testing regime that we hoped could at least be saved by the manual calls for testing. Here the breakage was missed, attributed to the wrong version, and no escalation happened to pull the update or to fix it before the point release.

Relatedly we now noticed that a lot of people (including Debian Developers) don't seem to know about -updates. So there is a gap that we need to address. It has been configured by default by automated installation processes, but there is surprisingly little to no user documentation about it. It replaced the archive volatile at the time and that's how we communicated it.

But a lot of these decisions are for the current release team - I'm not actually an SRM anymore even if the article claims that.