I believe Pine and IMAP4 servers (I know of at least 4 independant
implementations) are examples of handling nested multiparts on the client
side. Pine numbers the parts in such a way that the nested structure is
clearly visible to the user. IMAP4 parses the MIME message into a
hierarchical structure which preserves the nested represntation.
I am curious what will happen if the IESG rules that there isn't enough
support for generation of arbitrary nested multiparts through a
reasonable user interface. The nesting structure of MIME is widely used,
although it is usually used for special purpose sub-structure
(multipart/appledouble, message/rfc822, multipart/security, etc) rather
than general purpose hierarchy (although there seems to be plenty of
support for displaying general purpose hierarchy in messages).
As for multipart/parallel, it does not seem to be widely implemented, nor
does it seem to be an important part of the spec. One reasonable option
would be to remove the text from the spec and place it in the IANA media
type registry.