better than expecting the consumer of the API to take care of that
It's really an Overseer specific thing though - I don't think it's a problem for the consumer of the DistributedQueue API. We are dealing with special Overseer considerations, and I don't really see the strategy for that as a consumer.
A standard consumer of the queue API does not necessary need to detect this kind of zk connection flap - It's kind of Overseer specific I think.
Adding may actually hurt the distributedqueue consumer experience - you expect to keep working the queue in the face of zk connection/disconnection without any special handling.