Thanks for putting these mock ups together.
Without trying to rehash the long discussions in the sprint, when interfaces are disconnected certain things will not work indeed, and that's part of the point of having interfaces in the first place. The network example provided is a good one: disconnecting it allows the user to make an application local. A proper application will just report that the network is off, as that often happens for many other reasons.
For cases which are indeed less usual to disconnect for a normal user (say, "opengl"), I think what we should have is an ability to flag an interface as "advanced" in the interface model itself, so that GUIs can learn which of those should be separated out.
It's good to remember that interfaces won't necessarily come up connected, though. Some interfaces deemed dangerous and not fundamental for an application may in certain cases be left out of the auto-connection case. So we need to also think in terms of "Would someone want to connect it?" instead of just "Why would someone disconnect it?". Having no good means of connecting such interfaces may easily backfire, as it increases the pressure of having the interface connected in the first place.
Finally, there are indeed interfaces that pretty much never make sense to show up. "core-support" would be one of them. That might be a different value in the same field that flags interfaces as advanced.
For example, something along the lines of:
visibility → default / advanced / hidden
This would be defined by the interface type itself (snapd code) instead of being a per-snap setting. Lack of a value would imply "default".
