OK, but your examples are totally wrong and useless. You are looking at this in the wrong direction.
If someone uses a plugin then this plugin must support the api, not the way around, that osclass must support any plugin automatically with rest api, this is impossible, cuz plugins are made by 3rd party. And if someone creates a plugin then the support for api, must be in that plugin, coded by the creator of the plugin.
And the same thing goes for mobile app, if someone want to use a plugin in api, he need to code that support, first in plugin, second in app.
You are looking for a nice solution for a problem that doesn't exists.
In your examples, cars attributes, the site owner knows that he will use that plugin, so he knows that he need to have additional fields in his mobile app, this needs to be integrated together.
And the app don't need to get fields from api, it already knows what to send, cars plugin needs to be extended to support the api search of oclass code.
So in the api search in oclass, there will be hooks like: "api_before_search", "api_after_search", the first allows to add conditions, the second to add fields to results. The plugin just needs to support them both, then the app can send additional fields and thus receive also additional fields, per item.
You can even not change a thing, cuz if you activate the cars attrubutes and the code for api and normal search will be shared then thats it, if you request it from app, with the right fields, it will just work.
The app can make any request someone desire, so as for visual filtering, dropdowns etc. , this is also the plugin creator responsibility to add also an api route to get make and model for the app that needs it.
Social plugins, the same thing, api hooks need to be added to osclass login/register etc. code, the app owner need to add his OWN UI and code to support that in the app, the social plugin will need to support the api hooks that osclass adds.
Payments plugins, the same thing, if it adds a page then app owner needs to support in his app, but also the plugin need to support new api hooks to return all data that are need in app to make it happen.
The app will know what to show cuz it needs to be coded, there are no magic here, everything will not make itself and work automatically.
So yes, a lot of plugins will not be compatible with api at start, but in time they will be updated.
Osclass just need to make the right api hooks in the right places, to allow send any fields to the core functions that are needed and to receive the results.
Hook are great, cuz you don't need to use them if you don't want to, if a plugin changes the view/html/js, nothing of this will return to mobile app.
That is the whole point of api, send data, receive data, and of course that means many plugin will be at start incompatible, it is perfectly normal.
Just look at wordpress rest api, i mean they didn't check all existing plugins compatibility right? Yeah, it is just a separate entity, you can use it, but you don't need to.