But that improvement may tell you that it’s not (all) to blame on the GSM gateway?
A gateway will just transmit at the time the network tells it to. If the downlink arrives at the gateway too late to be transmitted (due to network latency), then it will not transmit it at all; it will not transmit it with some delay, but discard it. So, if changes in the device make downlinks work better, then at least part of the problem is not in the gateway.
I’d investigate if the uplinks between the different versions of LMIC are different. Like if there are any differences in the join procedure of the two LMICs. Maybe they start OTAA with a different SF, maybe also making TTN make a different choice for RX1 or RX2? Or, if you are in US915 or AU915, then maybe MCCI supports the initial ADR Request with some network configuration? (I don’t know if those settings affect downlinks. For EU868, LoRaWAN 1.0.2 includes some details in the Join Accept, most importantly also configuring RX2.)
If you cannot find differences in the uplink SF or downlinks, then I feel the improvement you saw indeed tells you that failing downlinks are not (all) to blame on the gateway. So even though the ethernet gateway seems to give you better results, you’d still have some investigation to do.
Aside: for Basic Station, does anyone know if TTN leaves the choice for RX1 or RX2 to the gateway?
Station will choose either RX1 or RX2 transmission parameters, whereby RX1 is preferred. If the frame arrives too late or the transmission spot is blocked, it will try RX2. To force a decision, the LNS can omit either the RX1 or the RX2 parameters.
Given one example message I found, it seems TTN forces a single choice indeed: