I do not have a license of P6 therefore cannot be of help here, I will not be able to give you the details to look for the parallel critical paths.
Nevertheless I would warn you that while MS Project does not attempt to calculate resource critical floats P6 attempts in frequent occasions fails and yield wrong values. I tried a very simple job with a colleague using P6 and it yielded zero total float for some activities while it displayed some free float. This zero total float makes it obvious that displayed free float is wrong but what when total float is not zero but reduced by resource leveling and free float is wrong?
I understand that P6 longest path under resource leveling stops the search when activities in the path are delayed by the resource leveling algorithm, therefore it might be somewhat limited. If using P6 I would not trust float values and would try to make best use of longest path.
Many times the best way to start crashing a schedule is by using a software that has good resource leveling algorithms it will yield a shorter schedule than others without need to crash activities. At other times the best way to get back in time a job is not by crashing activities but by making more resources available, manpower and equipment, or by use of shifts. Here again MS Project and P6 are very bad at resource leveling as well as with the handling of shifts, especially when you do not know how much work is to be done by each shift.
At home when a job start getting delayed we recover time simply by adding a weekends shifts, usually Saturdays is enough. We plan for a five days week and use weekends as our buffer if there is no condition that does not allow us to work on week ends.
As you can see crashing a schedule by an algorithm that optimizes which activities to crash usually misses the point by a wide margin. All those attempts to crash a schedule using time-cost trade offs have been abandoned decades ago. Solving real scheduling problems is not that simple.