

There’s not particularly good reason to stop doing it in that scenario either.
You have an offline technology stack in that elevator that has been doing the job correctly for 20 years. Why take on the expense and risk of changing things that aren’t currently broken?
It would be crazy if you are building new to resort to that stack, but for an established elevator, why bother?
Same for some old oscilloscopes at work. I’m not crazy about the choice but I can hardly suggest it would be practical to change it while the oscilloscopes still do their function.
I would say it’s a problem if the stack is online, but if it is self contained, the age of the software doesn’t make it a problem in and out itself.
I will second the suggestion at something like “expanded support for more image formats”. One of my responsibilities is rolling the development log into customer release notes and I agree with the “changes that highlight a previous shortcoming can look bad”, and make accommodations for that all the time. I also try to make sure every developer that contributed can recognize their work in the release notes.
“Expanded image format support” seems like something that if a customer hasn’t noticed, they would assume “oh they must have some customer with a weird proprietary format that they added but have to be vague about”. If it were related to customer requests, I would email the specific customers highlighting their need for webp is addressed after pushing the release notes