the root cause of this is the font subset in the first pdf should be unique, it should be given a random subset identifier that marks its uniqueness, problem is that its only unique at the bottom level of how its identified, the next level up identifies the font as either a code or a name as to what the font is, so if you try to edit the text and you have the Font you CAN edit it without having just the subset. So when you place and re-postscript or re-export, IF the program that does this bit decides to use the code or name (rather than retain the subset) things go wrong.
With your workflow you have multiple points for this to go wrong postscript 1, Distiller 1, Jaws (placing pdf1 into Quark), postscript 2, Distiller 2.
With Mike's workflow: Jaws1+postscript 1 (both these are called upon for Direct Export to PDF from Quark 9), Jaws (placing pdf1 into Quark), Jaws2+postscript 2 (Export to PDF2).
Erik's workflow: postscript 1 (Export to EPS), place EPS 1 ( no internal interpretation needed, except to build screen preview), postscript 2, Distill to final PDF. This works 99% of the time because EPS1 is exactly the same code as EPS2 so Distilling either gives the same result.
The big Difference is that Quark 9 (certainly quark 3-6) can pass the whole EPS untouched straight into the final postscript without interpreting it at all (unless you throw some transparency or color management at it). With a placed pdf, even with the later versions of Quark, there is still interpretation and re-writing of postscript behind the scenes.
Mike's workflow will probably be more successful than yours but its still got plenty of leeway to go wrong, Quark's interpretation of PDFs has got better (in my opinion through to v2016) since v8 but some posters reckon v9 was the best.
AFAIK Quark (any version) can not pass through a placed pdf 100% unchanged to a second pdf.