Tying the seqno request entry to the destination had the problem that when that destination neighbour entry was removed, we'd remove the entire request, and thus no longer retransmit it. Tying the entry to the neighbour on whose behalf we are forwarding the entry instead means that we can just clear out the neighbour from the request entry when we're removing it, as long as we keep a separate flag specifying that it's a unicast request.
This paragraph is not entirely clear to me. Do you mean that the neighbour on behalf of which we're forwarding the request has gone away?
Rather than complicate the request tracking, we just change the requests sent in response to an unfeasible update to be one-off unicast messages without any retransmission tracking. This should be OK, as we'll send another request the next time we receive the unfeasible update anyway.
Note however that Babel is designed to run reasonably well with very large update intervals, so the next unfeasible update might not be coming soon. I agree that the request tracking is the most complex part of Babel, though, so it makes sense to take some shortcuts. (Actually, the protocol was designed so that all the intervals (Hello, IHU and Update) can vary dynamically, and it would make a lot of sense to increase the Update interval when we detect a large, stable network.) -- Juliusz