you can't *assume* that a plugin will continue to work from one version to a next.
"plugin developers - please, urgently, test your plugins with 4.5"
That wasn't the problem this time. It is not those who upgraded to 4.5 found certain plug-ins not working, rather something unexpected.
The plug-in developers, at least in the two examples above, made their plug-ins 4.5-compatible. The problem was, that broke the 4.1-compatibility, taking the PHP range it'll run, beginning 7.4, in to account. So people who didn't do anything other than updating Moodle from say 4.1.12 to 4.1.14 or upgraded a plug-in that started nagging, found them breaking the activity or breaking the whole site. You need to read the two threads carefully. I know, long and winding.
What I see from a distance is that at the rate HQ is making changes to the core and API, plug-in developers will be forced to maintain more than one version (to support all the supported versions).
The idea behind the new numbering scheme (from memory) was that Moodle core will have "generations" or "series" or whatever, say x.0, x.1, x.2 and x.3, ending in a LTS. Adventurous changes are to be postponed to the next generation. In the case of the filters https://moodledev.io/docs/4.5/devupdate#filter-plugins broke that. It was introduced an interface change in Moodle 4.5, the LTS, which made the new version of the language filter incompatible with the previous and the still supported LTS, the 4.1.
The case of hvp was similar, the difference was that hvp is a core plug-in. So all those who upgraded to 4.1.14, that came together with 4.5 LTS, hvp broke!
The language filter got a patch. The latest version now runs with 4.1 and 4.5. The hvp needs a "patch", a single liner, to the code, for it to run in 4.1.14. (Haven't tested yet, too hectic.)