Expected ALTPLL behaviour

If your user-entered phase shift for the PLL is not zero, then even with the Classic Timing Analyzer you can see a better breakdown of the PLL timing numbers in the list-paths details. (I agree with Rysc's recommendation to use TimeQuest.)

When you turned on "Enable Clock Latency" in the "More Timing Settings" dialog box, you said that did "not change any of the reported numbers." You showed list-paths details for tsu. This setting doesn't help the list-paths reports for I/O tsu/th/tco/min tco. For register-to-register paths, however, it will separate the PLL compensation delay from the user-entered phase shift. That makes it easier to make sense of what the PLL is doing. Even if it is only I/O paths that you care about, you can look at a register-to-register path (if there is one) using the same PLL clock output to see the PLL compensation delay listed as a separate number. If you have register-to-register paths only on a different output of the PLL, you can still use one of those paths to see the same compensation delay. Just keep in mind that the line for the user-entered phase shift will be for that other PLL output.

If you want to try TimeQuest quickly for just reporting purposes (not to use during compilation where it would need to be completely set up correctly), then the automatic QSF2SDC conversion might be good enough. I/O timing constraints and some GXB clocks might not convert well, but you'll be able to see how TimeQuest reports the numbers for ordinary PLLs. The constraints needed for correct analysis and reporting of internal register-to-register paths on non-GXB clocks will probably convert fine.