The question about your proposal is what does versioning of the API brings over the last part of your proposal (That match mine, see the OpenSubsonic API extensions - Symfonium support part of the forum) [Expose supported extensions]
The goal is really to limit the burden to the servers devs to the minimum, adding a versioning API means they need to comply with it and all the end points. And if in all cases the clients needs to check what is supported or not if a server does not implement everything then it does not bring much.
We just need to ensure a conflict free or versioning of each of the extensions.
So in your case /rest/extensions/supportedEndpoints (Would change the name to support other addition than endpoints, like supporting post, or just new authentification system) it could return a list of function with versions.
In json would be
[ { "authentication": 1}, {"songArtists": 2}, ...]
IMO also as said in the answer to @lachlan-00 we should allow non breaking change to current API to again remove some work on the server side.
Like if we want to return new fields to media, it would requiring adding new versions of all the current calls that can return media, that’s a huge amount of work for no gain.
In that case it’s easier to just write a new better API from the start.
TL;DR: If we add too much rigidity and force many new endpoints for small changes, it’s probably better to directly write a proper V2 API schema that would be better and future proof. But that’s another story and much harder to convince everyone to see a benefit in it.
That would mean like 3 API for Ampache, they would have no reason to generate more work for them for any internal change they make to still maintain all those API.
I’ve added you to the group on the subforum.