The only code that would be affected that I can think of is the USB detection code. The let's split code detects the presence of the USB port by checking the UVCC pin of the ATmega32u4. Compare the schematics of the two boards:
On the Teensy, UVCC is directly connected to 5V from USB and the 5V supply. So when it is powerd by the TRRS cable connected to VCC pin of the Teensy, the Teensy will see 5V on UVCC. So the let's split code will think that the USB cable is connected as UVCC == 5V.
(Ignore annotation) On the pro micro, the UVCC supply is separated by a diode. This means that the ATmega32u4 will only see voltage on UVCC pin when the micro USB cable is plugged in. If it is powered by TRRS jack which is connected to VCC, UVCC is disconnected because of the diode, so the controller will know that it is not being powered by USB. (Note: that the jumper SJ1 on the pro micro has to be left open for this to work)
An easy way to work around this would be to force one side to always be the slave and one side to be the master. To do this you would
change this function to always return true for the master, and always return false for the slave. You would have to compile two different versions of the code. Of course if you use this method, the side you designate as the master must be the side connected with the USB cable.
If you want to be able to connect the USB cable to either device, you will have to implement a more advanced method. When the device is powerd on, you would initialize the USB controller and wait to see if the USB controller is able to communicate with the host. If we observe any communication, then run the master code. If no communications are observed after a short period of time, then run the slave code. If you want to try this method, you could probably [hook into this function](
https://github.com/qmk/qmk_firmware/blob/master/tmk_core/protocol/lufa/lufa.c#L331).