You raise some good points - I hadn't been explicitly considering the use of Einhorn::Client by other bits of code. 

Working through how this would actually be used - I think there are two main use cases: an event driven app where you set up a number of listeners and act on their responses as they come in like your stats counter example or a command/response based app like einhornsh. The first is easy using a callback style, in pseudo-ish code:

``` ruby
@client.command("subscribe", "respawn") do |response|
  stats.increment("respawn")
end
```

The problem comes with the second use case, where you want to break out of the loop once one or all of the commands you've started have finished - to do this you either need to have multiple callbacks (this isn't node) or handle the wait attribute in client code:

``` ruby
while command = readline() do
  @client.command(command) do |response|
    puts response['message']
    return unless response['wait']
  end
end
```

Even this simple looking code raises some questions - is returning from the block part of the API (and does this work in both 1.8.7 and 1.9?) or should it be based on the value returned from the block? How are exceptions handled? Does this allow for ctrl-c interrupts? And so on.

Alternatively, I'm starting to think that the change to a callback interface is a mistake, and you could just provide a `send` and `receive_message` method and put all of the logic back into the calling client:

    # stats counter example
    @client.send("subscribe", "respawn")
    while message = @client.recieve_message
      stats.increment("respawn")
      # there's nothing stopping you calling @client.send here
      # or implementing your own request-id-based lookup code
    end

    # einhornsh
    while command = readline() do
        @client.send(command)
        while response = @client.recieve_message
          puts response['message']
          break unless response['wait']
        end
    end
    
This puts more logic into the client code but makes the API conceptually simple, and makes the common cases easy without preventing more complex apps from being written where needed.

Thoughts? Did I miss anything?