The MC application should ideally be split into two separate applications..
1) MC Player should become a Windows Service Application. This exposes no UI at all, and runs when Windows starts. It always runs in th background regardless of whether a user is logged on, and regardless of whether th UI application (see below) is running.
2) MC Browser should be (should remain) a Windows Application. This exposes the whole UI, including track browser, play commands, playing now, tagging, audio analysis, file rename, copy, move etc. It only runs when a user starts it. And stops when the user stops it.
The Browser application talks to the Player application by means of standard Windows interprocess calls. In the case of MC, probably either by the COM interface, of MCWS.
I know that this architecture can work, since this exactly how Logitech Media Server (Squeeze Box player) works. And my own Whitebear Media Server UPNP shim for LMS works also in the same way.
This is quite liberating as a design architecture, since it represents a real and proper split into the client/server architecture.
PS if MC were ever to shift to a 64 bit build, this would be the perfect opportunity to split the application into client (regular application) and server Windows Service Application) parts..
And indeed when MC is operating as a networked client/server application across several PCs it is in fact functioning virtually as described above. It is only in the case when MC is operating on a single PC that it does not clearly separate the client/server parts.