The "matching" you mention may not happen in the snappy case. So there is a problem.
In the pure snappy case, an app brings its own libmirclient and potentially its own libmirprotobuf and libmir*. So it is not a binary "match" for the server in question. And the app may be using Mir binaries that are newer (most likely) or older (e.g. this bug) than that of the server. The only commonality is the protocol and negotiation needs to happen there. It's not related to libraries and ABIs at all. Unless.....
We could mitigate the problem by:
(a) Never bumping the client ABI again; and
(b) Ensuring app snaps don't bring their own libmir*, so do use the system copy.
However that only works for as long as we can ensure both (a) and (b) are true.
The "matching" you mention may not happen in the snappy case. So there is a problem.
In the pure snappy case, an app brings its own libmirclient and potentially its own libmirprotobuf and libmir*. So it is not a binary "match" for the server in question. And the app may be using Mir binaries that are newer (most likely) or older (e.g. this bug) than that of the server. The only commonality is the protocol and negotiation needs to happen there. It's not related to libraries and ABIs at all. Unless.....
We could mitigate the problem by:
(a) Never bumping the client ABI again; and
(b) Ensuring app snaps don't bring their own libmir*, so do use the system copy.
However that only works for as long as we can ensure both (a) and (b) are true.