You may be making this more complex than it needs to be. The first message back is processed as valid. There may never be another message so waiting to see if a duplicate will arrive is waiting for something that may never occur. If another ALDB message is received it is analyzed against “is there is pending ALDB response expected”. If not then it is ignored as a duplicate. You will see multiple Group Broadcast messages from RF based devices such as Motion Sensors, TriggerLincs and RemoteLincs. Also the Controller has already retried a command if a response it not received or a NAK is received. There is no reason for the application to retry more than the Controller has already done before the application receives the final NAK.
The exception would be the ALDB request. Some devices indicate I2 engine support but do not send an ED ALDB 2F response. Some HA applications will reissue the ALDB request after waiting a few seconds just to be doubly sure the device will not respond with the ED ALDB message. The application must resort to the old Peek/Poke method under these conditions. The exception to going back to the Peek/Poke method is where a Motion Sensor or TriggerLinc is being accessed. These two device types did not implement Peek/Poke so should an ED ALDB response fail to come back it must be taken as a permanent error.