Correct and Unshipped
A patch can be fully written, reviewed, and sitting in a branch for years without shipping, and the diff was never the problem. Nobody was stuck on the code. They were stuck on the line they'd have to draw around who still gets to talk to the old system.
Call it the cut line: the version, client, or protocol boundary below which support stops. Shipping the fix means drawing that line somewhere, and drawing it means someone on the other side of it breaks. Not a hypothetical someone: a support queue that fills up, or an integration partner's automation script that starts failing the morning the patch lands.
The severity of the vulnerability has almost nothing to do with the size of that queue. A cipher suite everyone should have dropped a decade ago and a cipher suite that's actively catastrophic both require the exact same cut line, the same list of who's still negotiating with it, the same volume of "why did our integration just stop working" tickets the week after. The bug's score changes how loud the conversation is. It doesn't change how many old clients you have to cut off to close it.
That's the part a severity score can't hold. The rubric measures exploitability and impact. It has no field for "number of customers on a three-year-old version who will open a ticket the day this ships." That number is the real gate, and it moves independently of severity in both directions. A low-severity bug can ship the same afternoon it's found because almost nobody's on the affected path. A severe one can sit for years because half the install base is.
So the fix waits, correctly documented, technically five minutes of work, while the actual project runs in the background: enumerate who's still on the old behavior, decide how much warning they get, write the deprecation notice, staff the support load for the week after, argue with whoever owns the relationship with the biggest holdout. None of that is engineering. All of it has to happen before the one-line patch goes out, because the patch and the boundary are the same commit whether anyone admits it or not.
The asymmetry is the part worth sitting with. The cost of shipping the fix lands on whoever owns support and whoever owns the relationship with the client that breaks. The cost of not shipping it lands on whoever eventually gets hit by the thing the patch would have closed. Those are almost never the same people, which is exactly how a fix stays correct, known, and unshipped for years at once: the ones who could ship it aren't the ones who'd pay for the hole, and the ones who'd pay for the hole get no vote on the cut line.
None of this argues against deprecation. Eventually the line gets drawn, usually after an incident makes the decision for you instead of a planning meeting doing it on schedule. The point is narrower: don't read "still vulnerable after all this time" as evidence nobody understood the problem. Read it as evidence of how big the list on the wrong side of the cut line had gotten, and how long everyone managed not to find out.
The patch was never the hard part. Deciding who to leave behind was.