LLAPI - Does QosType.ReliableStateUpdate overwrite its ack in the ack buffer?

When using the QosType.ReliableStateUpdate or QosType.StateUpdate, it only takes 1 (or actually it seems it takes 2?) spots in the send queue no matter how many times you send it.
What I would like to know, is if I send a ReliableStateUpdate message, and it goes over the network, and then I send another ReliableStateUpdate message before the ack for the first ReliableStateUpdate was confirmed, will this new ReliableStateUpdate message overwrite the ack of the first ReliableStateUpdate?
In other words, when I send the new ReliableStateUpdate message, will the LLAPI then decide that even though the first ReliableStateUpdate message wasnt acked yet, we can safely remove it from the ack buffer since we dont care about it anymore since we are sending a new ReliableStateUpdate message?
If it doesnt, then why not?

I tried testing this myself on a localhost connection, but the NetworkTransport.GetAckBufferCount always said 0 even though I set the ConnectionConfig.AckDelay to 5 seconds and the ConnectionConfig.MinUpdateTimeout to 5 seconds as well.
(I also noticed unreliable messages get sent instantly, while reliable messages dont, and sometimes the reliable messages make the NetworkTransport.GetOutgoingMessageQueueSize sometimes show a value higher than ConnectionConfig.MaxSentMessageQueueSize, possible bug?)