The connection system is a very basic adapter layer to the ZK C API which essentially does everything in a 1:1 manner. This isn't the most wonderful system in the world. A more ideal system would be something AFIO-like (think Linux syscalls __NR_io_setup, __NR_io_destroy, __NR_io_submit, __NR_io_getevents). The real goal is to make the system pollable so users can plug ZK bindings into epoll-driving application frameworks.

class connection
{
public:
    using native_handle_type = int;

    virtual native_handle_type native_handle() = 0;

    virtual void submit(operation) = 0;

    virtual std::size_t receive(ptr<result> out, std::size_t out_size) = 0;

    /** Try to receive a single result from the system. **/
    optional<result> try_receive_one();
};

Ultimately, this puts more of a burden on the client implementation, but given that every call in it is currently just _conn->do_thing(args...), that's probably okay. The general idea is that callbacks, state changes, and watches are a problem of a client, but not of the low-level connection.