Ethernet is not in the game here. It's a TCP connection between LwIP and a TCP client running over PPP. It happens only on the slow netif (PPP) as Ethernet is too fast to see that issue. Hence I think that >99% of the LwIP users will never face this.
If i run the same connection over ETH instead of the slow PPP link, I can't see it either. It seems to appear only if the first fragmented packet is still in transmission and the next arrives, ETH is too fast to get to this situation.
The matching segment numbers are indicating that it appears to happen in the TCP part of the stack, if data would be lost in PPP and a fragment would get lost, the sequence numbers would indicate this. As the seq numbers are perfect even with the "silently dropped" second fragments of the packet I assume it happens before the fragments are numbered. Could it be that pbuf's of the TCP send queue are overwritten by the second packet if it arrives while the first one is not yet sent out?
Well, on a system with PPP *and* standard ETH, you obviously can't wait for the serial interface to transmit before serving ETH?
Simon