When we consider autoconnection candidates we look at both plugs and slots of the refreshed/installed etc snap:
starting from its plugs we try to find whether there’s a single slot that would match the plug, this seems to make sense,
starting from its slots we also try to find whether there’s single plug that would match the slot, this doesn’t make sense, in general we allow multiple connections to a slot atm.
Good point, thanks for spotting that.
This is true, I added extra logging around auto-connect and confirmed this finding.
I think that for content and network-bind we should auto-connect all plugs, not just one, unless they are already connected but I worry that I don’t have a generic answer. Should this be something each interfaces can influence?
Well, as long as we don’t have a way for slots to block/limit connections, I think all we need to do is just make the logic properly symmetric. So the behavior that we need to make happen should be as if all the other snaps in the system get refreshed after this one snap we are operating from.
Right, equivalent to. Let’s please not do exactly as. 
Yes, my point is that those would trigger a bunch of (re)checks for auto-connection starting from plugs to our (new) slots. We need to produce the same result in terms of connections.
