Yes, you are not wrong here.
What I regularly have to deal with is about as bad. Big project, and every upgrade replaces one key element. They have never heard of backwards compatibility. If they don’t like a subset in their system, they replace it. Complete with different API calls, structures, and calling conventions. And they may document parts of it three versions later. If at all. Some documentation is basic Doxygen - just list the function parameters, and that’s it. I’ve seen cases where the documentation of the rather critical parameter “flags” was just the word “flags”. I’ve seen cases where the return value was documented only as “status”. Not even with a notion whether 0==success and 0!=failure or vice versa.
And no, it is not a closed application. They have an “extension” folder for user-supplied extensions. The problem: If it is not a core extension that has been updated with the main project, the first thing after an upgrade is finding out where your formerly working extension critical to your project now fails, because they just happened to think that the call interface for the boogaloo object need a complete overhaul. Maybe it needed an overhaul, but then at least keep the older interface alive for at least a few versions after documenting the new interface and marking the old one as deprecated.
I’ve seen cases where the documentation of the rather critical parameter “flags” was just the word “flags”.
In Microsoft documentation it would just say “FLGs”, with no explanation of what FLG is, nor any links to resources about FLGs. you either already know what it is or you now can’t continue any further with the documentation (because a search for FLG also fails to find what it is). Throughout their documentation it is heavily assumed you are a long-time Microsoft programmer and already know all of this. i.e. it is completely unwelcoming to Microsoft beginners (and even some who aren’t beginners)
