To follow up on what Ed Levinson said ...
Multipart/Related expects to know the content-type of the object root,
the body part with which to start processing. If the root is inside
a Multipart/Alternative, that adds an additional level of binding or
indirection that must be resolved before the MUA can determine which
helper application gets invoked.
Ed
What does it mean to "start processing?" If the prime
substructure in a Multipart/Related happens to be a
Multipart/Alternative, then processing starts by resolving which
of the alternatives to employ. It doesn't start by selecting a
helper from the "root type" information in the top level
composite. But it knows right where to start, and how.
If the RFC actually restricts content-type [as applied to the
root] to be a fully-resolved, non-multipart type, then this
language is in conflict with the language elsewhere that says the
composition methods recurse.
As you will probably have guessed, I would vote to "save the
trees." But I don't need to put any tree-descriptions in as type
designations in any of the multipart aggregators: so long as I
can use multipart types to characterize the child parts.
Al