What you need is an implementation of the Asynchronous Token
pattern that is handily available to us in Flex as the AsyncToken class. If you are using Flash, then unless you can find an implementation of it, you'll have to roll your own.
Basically, the way it works is
1) The user follows one of a number of use cases that causes the client to invoke a service.
2) The client invokes the specified service, and the synchronous result of the call is an object called a 'token'. The token is a dynamic object you can add properties to on the fly, and the service call sets a unique id or serial number to the token before returning it to you. It also sends that id to the service.
3) After making the call and receiving the token, you set one or more properties on the token that help you remember what you were doing when you made the call (e.g., which call was made, data that was sent, etc.)
4) The service sends a response to the client, including the token id.
5) The client matches the response with the appropriate token and voila, you can resume where you left off (e.g., sending the correct notification based on the call that was made.
Now in Flex the AsyncToken is returned to you, you set properties on it and don't even bother hanging onto it, because the response event will have not only the data from the server but also the token. And also your service doesn't need to accept the token as an argument and return it, it's handled 'out of band' by Flex.
But if you're rolling your own, you may have to add a token id to your api and return it in your response. And hang onto the token in an Array or Vector in the ApiProxy. On getting the response, get the token id, splice it out of the Array or Vector, and use it. I'd say have the UserProxy pass in the notification name that it like to have sent when the response comes back. That way, when the ApiProxy makes the call, it sets that note on the token that it stuffs in the Vector and then when it gets the response, the token is telling it what note to send on success. You might want to send in an optional note for failure as well, if you have special handling for a given call, overriding a standard note that would be sent otherwise. And if you store the arguments for the call on your token then that might be useful for you when you are sending out a failure note....
Also, in your scheme you don't really need the UserCommand. You could just have the Mediator make the service call.
Hope this helps,