Antony, it looks like you're directly avoiding the question.
Reread it if you're not, it's super simply asked, in anticipation that there's an exact explanation and description possible, in similarly simple and exacting language.
Like you, and everyone else, and every instrument for analysis, I can hear the result.
But what is actually going on?
And, if you've read along, you'd have seen this is the basis of the question:
"Maybe start with a 2 Sine-Op Stack (1:1) ..."
at an amp of 99 for each.
turn off the condescension, if you can, and just think about this mathematically, such that it's then possible to extrapolate out what will happen at other ratios, and reason about what's occurring.
"If you can't explain it simply, you don't understand it well enough."
this most certainly applies to most folks attempting to describe the mechanics of FM sound synthesis as it's performed by FM-X, with the possible exception of Brian.
I suspect a huge portion of this is a terminology problem, that we're all trying to wrap our heads around what's happening from a position of frequency modulation, or words that convey that to be what's occurring, when what is happening is much more akin to phase modulation of some sort, with some arbitrary constrictions as per Yamaha's insights into what might be musical, and easy for them to program around chips of their design, way back.
Since there's a flavour favour for the folly of analogies, permit me one:
This endeavour to unwrap what's happening in FM-X seems troubled by terminology akin to explaining OOP (Object Oriented Programming) from the perspective of an orientation to objects - anyone falling into this trap winds up in a knotted pretzel of animals, blueprints and car models, and their readers/listeners further back than when they began.
This is because it's actually Signals Based Programming, as per the originators of thinking on the matter, someones that took knowledge of signalling systems for granted and therefore forgot to predicate any insight and consideration of objects with at least some prefacing of how strongly they favoured and considered the sanctity of signalling between "objects" over all else.
Once the realisation of the significance of signalling is understood and reasoned about, OOP conception is simply: sources and destinations of signals choose their level of sanctity and responses, which are used as determinants of subsequent signalling. It's signalling all the way down, and up.
This frees the thinker from the tyrannies and troubles that terminology dependent 'teachings' of tooling torment the mind with in "OOP". Things like: inheritance, encapsulation, interfaces and polymorphism can be shelved - as putting the focus back on how-and-why-to-do-what with signals inherently reveals usage for these mechanisms as mere incidentals realised in support of signalling methodologies.