One alternative to solving the multiple calls approach is to have a dedicated responder class to handle the result calls. On each call invokation, the client class creates a new instance of the responder class and registers the appropriate event listeners on it. Because multiple successive calls to the same method will generate multiple responder instances, there is no “multiple calls problem” because each responder instance will respond to its own set of events (and be unaware of the others). (For best practices, the responder class should be made internal to the package since clients don’t need to know, and to enable refactoring.)

That being said, I really like the closure-based solution — it’s far more readable and compact, and it doesn’t require a second class to handle events. If I wasn’t nearing a deadline I’d consider refactoring my code… :-)