Here's an FYI to the devs on what I've found for the referenced bug report. I added this info to the bug report, but wanted to give an FYI to the devs as well in case anyone had any idea for tuning the method in question.
I loaded the save game and tracked the problem down to UnitAutoChooser.java. In the solveCandidateCompositeCategories method (under the while(true) loop), it's doing something that in essence looks like it will execute n! times, where n is the number of transports.
I'm not sure exactly what the method is doing as I have only just narrowed it down to this method. Looking at the indexStack and curIndex through various iterations, I see that it curIndex initially counts up to the number of trns. Then when it checks to see if the stack is empty. When it's not, it pops the next lower value to the index and repeats.
So in this example it runs the loop 23 times, then sets the index to 22 and runs 1 time, then sets the index to 21 and runs 2, then index=20 and runs 3 times.... I'm not sure what happens when it gets back down to an index of 1. I'll try to run through it and see, but since the app eventually comes back, I'd say the stack is empty at that point and it hits the break command.
Here's a further update.
Looking more closely at the loop execution, the number of iterations may be even more than n!. Here's a sample of what the currIndex gets set to upon the end of each iteration (after spinning through it down to 14 to get a good sampling of the process):
22, 21, 22, 20, 22, 21, 22,
19, 22, 21, 22, 21, 22,
18, 22, 21, 22, 20, 22, 21, 22, 19, 22, 21, 22, 20, 22, 21, 22,
17, 22, 21, 22, 20, 22, 21, 22, 19, 22, 21, 22, 20, 22, 21, 22, 18, 22, 21, 22, 20, 22, 21 ...
Each successive decrement gets longer and longer, and so I can understand why it goes into La La land.
I can see a pattern in it, but I'm not quite able to put the pattern to words.