It should not fail install (there is simply no candidate to connect and therefore auto-connect).
In terms of the original question, this all comes down to the fact that interfaces are contracts between the slot side and the plug side. In the normal case, to be a slot means to provide something to any snap that may plug it. We have several mechanisms and patterns to inform our processes and snap declarations.
For privileged slot services that should typically manually connect (eg, network-manager), we a) as part of process request that the provider’s publisher make a statement that they will not break consumers and b) issue a snap declaration allowing connection.
For unprivileged slot services that should typically auto-connect (eg, mir), we a) as part of process request that the provider’s publisher make a statement that they will not break consumers and b) issue a snap declaration allowing connection and auto-connection.
mpris falls outside of these patterns because while we don’t allow auto-connection, we will allow connection provided the snap uses the defaults for the mpris interface, which grants use of org.mpris.MediaPlayer2.<snap name> without manual review. Why did we implement it this way? Because binding to the well-known DBus name is a ‘providing’ action (it is just a specialized form of the ‘dbus’ interface really) and the mpris DBus is meant to be used by other applications. It is a slot by any reasonable definition and there didn’t seem to be any reason to deny snaps access to this standard API. We also knew that we wanted users to be able to connect controllers to snaps providing the mpris interface without needing the store to be involved (keep in mind, users who can snap connect are admin users and can modify the system in arbitrary ways).
The key point in my mind is that connection vs auto-connection for mpris is the only mechanism we have to express “you can connect it, but no promises” vs “we’ll let you auto-connect because the publisher says that you can trust it will work”. If we simply grant the auto-connection without talking to spotify, we as reviewers are making the promise that plugging snaps are good to trust it, but we aren’t in a position to make that promise. Conversely, as reviewers we’re saying to spotify that all plugging snaps are fine to connect, when we have no idea if that is true or not (perhaps they don’t want to expose the API to everything by default).
This particular request is for a particular lyricfier snap (as opposed to all snaps) to auto-connect to spotify, but as reviewers we can’t promise to lyricfier that spotify won’t break them and we can’t promise spotify that lyricfier won’t abuse the privilege of auto-connection.
I maintain my -1 to auto-connect until such time that spotify publishers comment that this intend for the mpris interface to be stable for snaps to use. IME, they are free to make the choice on a snap-by-snap basis or for all snaps.