Or your device is exceeding the allowed/expected transmission power, which also makes “connections” with a gateway asymmetric? Assuming your TTGO T-Beam uses some LMIC code, see LMIC_setDrTxpow.
While changing code: to mitigate any downlink timing problems, see LMIC_setClockError. (Though I’d guess that usually gateways do okay with their side of the timing. So if the TTIG Join Accept is received, then the node’s timing might be just fine, and the other gateway’s Join Accept should be received too, when using the same SF? I’m not sure though, and @cslorabox already explained that timing might be an issue if the SF changes. So, you might want to use a fixed SF as well? TTN Mapper recommends SF7.)
Without even making changes to the code: what if you move closer to the other gateway? Getting one proper Join Accept from the other gateway will tell you if it is actually transmitting any. You’re mapping anyway. 
Or maybe you can even become a collaborator of the other gateway, to see its traffic; see also How to contact a gateway owner?
Oh, and I guess that powering down the TTIG does not make any changes? Then it’s not really related to multiple gateways, but just the combination of your node’s position and the other gateway.
Some asides: for moving (mapping) nodes, ADR is not recommended; see Why is ADR only relevant for nodes at fixed positions? Also, a DevAddr is not a secret (and not even unique, and will change for every new OTAA Join anyway). Same goes for the AppEUI and DevEUI.