Hi Hitch,
After re-reading the complete thread once more, I was struck by this post by quiris:
https://www.mobileread.com/forums/sho...3&postcount=67
I think Peter's case is exactly this. From the PD/KDP response, the preprocessing step is being referred to as "font-fix" tool and when it detects elements with default fonts being overwritten/changed it acts to "strip fix" all embedded fonts.
The problem seems to be when they calculate an implied "main" font based on the total text covered by that font and then implicitly apply it to all body tags, and if that results in any element that should have been a default font changed, they strip all embedded fonts. My guess is they would do the same thing if an explicitly set body font did not match the main font as measured by amount of text covered.
This I think is captured by Peter's use of Palatino on a p tag - when it covers more than 50% of the text of a book it becomes the "main" font according to the font-fix tool and therefore an implied body font, and that results in some element changing from default to Palatino, which in turn is why they throw out all embedded fonts.
So, in short, having an implied body font that somehow changes the expected font of some other element, results in all fonts being tossed.
A quick and dirty python script could in fact calculate the "main" font in a fashion similar to their "font-fix" tool to help detect this condition before submission.
Anyway, that seems to be consistent with all of the evidence in this thread related to having all embedded fonts stripped out (not just one or two flakey fonts).
Hope this helps,
KevinH