Datagrams are not guaranteed to be delivered. It is part of their semantics. While you can potentially get a long string of successful deliveries on the blinks currently sitting on your desk with the current battery levels and the current firmware and the current temperature and light levels, if your code assumes this case then it violates the documented behavior and will be brittle when things change.
The idiomatic way to use datagrams under blinklib is to use idempotent messages that are controlled using state that is shared with the underlying setValueSentOnFace() values.
This is admittedly awkward. Ideally, I would have liked to have offered a setLargeValueSentOnFace( void *data, byte len) that worked exactly the same way that setValueSentOnFace()works just with more data, but this is impractical because of the way that blinklib does collision avoidance, neighbor presence detection, and it would generally be slow and wasteful sending all that big data over and over again. So we split the baby - but for the existing games that have used datagrams it seems to be an OK compromise.
If your game can live with the much higher latency for detecting a missing neighbor then you are certainly free to fork the blinklib and change time outs, but again I think you are trying to fit a square peg into a round hole (that is in a square hole). If you are going to fork blinklib anyway, mind as well get what you really want and do the packets (and neighbor detection) yourself.
(Note that if you kill all the blinklib coms you will be responsible for making sure that blinks that happened to not get button presses do not sleep prematurely - but you can almost certainly do this better yourself than the current method since you will be able to tailor your approach to how your specific game uses button presses. It is possible this will not even require extra bits in the communication if there is already information about game play events in the packets).