FWIW, I was able to replicate this problem in the new SU Lab environment.
One thing that I failed to mention in the OP is that it’s even more frustrating because in the SU print preview (before you hit the Print to PDF button), everything looks normal and you can fiddle with the view and get it just the way you want to see it in the PDF file. It’s not until you create and view the PDF file that you see the problems. Then you have to go back and forth using trial and error to guess what the appropriate layout of your callouts is to get a good output file.
Also note that another ‘feature’, that I find particularly annoying, related to PDF printing (should I create a new post?), is that they embed code in the PDF file that causes the printer dialog to open any time you open the saved PDF file. Not very cool if you want to share the PDF with someone to view (not, necessarily, print). I’m guessing the offending PDF language is:
6 0 obj
<</N/Print/S/Named/Type/Action>>
endobj
I understand that the intended purpose of the Print command is to print the file. On the other hand, I know of many other apps that let you print to PDF without embedding this language in the created PDF file…the user has to then initiate the print process. Unless they can implement a way to provide both features (print on output, but view when opened), I think the better course would be to not embed the print code in the PDF file…IMHO.