Actually …
I’ve been thinking about this.
And admittedly I’m thinking in terms of API’s and translation layers but if we change the angle of attack, this might work.
The problem though would be that everyone’s media interfaces may suffer as a result for the period until the change permeates all integrations.
So if the HA instance HAS to go through a common defined ‘media player function suite’ (an abstraction layer if you will. change name as appropriate) then ALL the required functions could be defined for all media players (and be available even if the ‘Bob’s media player’ integration does not support all of them).
So ‘you’ as a user, interface with the ‘media player function suite’ and that interfaces with “media_player.bobsmp_living_room” (or whatever) which is connected under the ‘Bob’s media player’ integration.
So this is a bigger task than just one integration, as a new layer would have to be created, agreed and published (probably not in that order 
) and all integrations tested with it. Then we have to live with it until any resultant bugs are ironed out.
This is quite an investment of time from both the devs and the authors of all the current integrations. With an upfront commitment from the devs.
First off though you’d need a full list of media player interface requirements. Easy ones are volume up, volume down, volume percent, power, play, pause, stop, next, last, source, position etc. Then you have the more difficult ones of resume_source, resume_position, resume volume, resume index, default media volume (maybe needs to be per source) , default tts volume, default tts play gap (that irritating chunk you lose at the start of tts) etc. (edit: you might as well include nice to haves, like favourite sources, playlists, shuffle, straight list, repeat one, repeat all, target player (easy) target group (more difficult), groups, synchronisation plus all the others I’ve forgotten).
It’s quite a big task but doable if there’s a will.
… And - who isn’t a squeezebox fan ? . . . :puzzled: . . .
