Somewhat related to this topic Command line interface to manipulate services - #47 by pedronis.
I think the last idea was to give some means of aggregate management of services (i.e. the service itself and trying to do the right thing about its socket and timer). Probably needs some discussion in the team, or at least getting @pedronis involved.
This indeed looks a bit off. We do not track whether the user disabled a service from a snap. However, I think that any attempts to track the state of services before the refresh and restoring it when enabling the new revision would need to work under the assumption that service names from the old revision are still valid in the new revision. Doing this automatically feels a bit fragile, given that snapd does not know whether the assumption is true for any snap. I would say that this is the job of pre-refresh and post-refresh hooks. The snap creator knows best whether, say service A from rev 1 is the same A in rev 2 or it is rather named B now and the hooks can act accordingly.
This brings us to the 2nd part of the problem. The output of snap services is sufficient to do the right thing in the hooks for the regular services. However, it lacks information about the state of sockets and timers. There were some proposals in the topic I linked above. I think this one could work: