In software development, and of course in other places in life, there's a concept of "low hanging fruit". These are tasks that may not necessarily have a high return on investment to the company or the system. But often these tasks are low effort and are a nice QoL for users or a morale boost for developers. This can be very nice when you're bogged down on a big project because you're getting *something* out there. I suspect this is what happened with the viera where developers put in their own time. It was nice for players but also a development morale booster when they could see how happy players were and know they had done something that was really appreciated. I'm similarly pleased when I'm not fixing a bug for my users but adjusting something they've had to make do with for years to make it easier for them.

If this alteration fits into the "low hanging fruit" designation, then I would support their work on it no matter if it's common or not. If there are factors we don't know about that make it more complicated, then I can understand having to measure the effort required against the return on investment and utilizing whether it's something that happens a lot as a factor of that analysis.

There do seem to be other places similar concepts are used, but since I've been there before, I'm not making any assumptions on that. It's not always easy or even possible to implement the same logic in one place that you have in another place. Especially if you're working on spaghetti code crafted long ago by someone else.