I believe I saw a release not explicitly stating that the popup client didn't work in environments with fast user switching, which is essentially what you are seeing here.
I'm not sure of the exact behavior with an active session that's not currently logged in, but I would bet that the idle user's launch agent would still work to ensure that the software is running. Given that the retry setting is 10 seconds, it should check for the idle user that the software is running and launch it again if it is not. I don't know how it would handle the conflict between the two accounts.
I would think that if you want the functionality to work you'll need to unload the launch agent for the idle user, make sure the service has stopped and then load it for the new user.
Alternately, rather than relying of fast user switching, you could have a launch agent that logs the user out after a period of inactivity, rather than relying on the screensaver. It would drop users back to the login screen, and should allow for printing normally.
Peter, we've encountered something similar, from OSX 10.6 onwards. We guest access to a couple of users' computers. When the Popup/driver package is installed on the user's partition (as admin), it works for them as it should. However, once they set the computer back to the user switching window (staying logged in) and the guest logs in, and tries to print, the guest does not see the Popup and cannot get their print to work. It turns out the Popup has popped-up in the admin user's partition, so the guest is stuck.
Something within user switching is failing to let go of the Popup process; restarting doesn't do it for us, it's all dependent upon where the Popup package is originally installed.