This didn't come true, for several reasons, some of which are more obvious than others.
To add insult to injury, the ISO/ITU comittee declined to give any advice on how to handle interworking between the "old" systems using X.400/84 and the "new" systems. This has been rectified in the appendixes of some newer recommendations, but is still limited approximately to saying that you can tunnel X.400/88 messages through an X.400/84 infrastructure using the content type P22; there is still no real advice on interworking between an X.400/88 UA and an X.400/84 UA. This probably reflected the view that "most people" would convert rapidly to the new formats; this didn't happen; even today, I believe that more X.400 E-mail is carried using X.400/84 compatible formats than is carried using the X.400/88 extension.
An IETF document, RFC 1328, specifies one way to do downgrading; extensions to this for handling stuff in a MIME-compliant way were defined in RFC 1496 (HARPOON). I don't know if there exists any large body of deployment for this stuff.
This means that a MIME message can be delivered to any RFC-822 compliant user agent; the text-like property of Internet mail means that it can be viewed to some degree when it gets there, and stored in a file without information loss.
This interoperability comes at a price, however; the encoding mechanism for MIME mail is rather ugly compared to other approaches like "just send 8bit and let the recipient beware": A message like this, using some ISO 8859-1 characters:
would be turned into something like this:Subject: Håreks damebesøk Håper du kommer snart
This notation is also possible, but rarely used with messages that contain "mostly ASCII-like" text; it is more sensible to use with binary file transfer and non-ASCII alphabets like Cyrillic or Kanji:Subject: =?iso-8859-1?Q?H=E5reks_damebes=F8k?= Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable H=E5per du kommer snart
Anyway, even the first notation is ugly enough that several people in the ISO 8859-1 community (Western Europe, mostly) denigrate it as "quoted-unreadable" and go on sending 8-bit SMTP messages.Subject: =?iso-8859-1?B?SOVyZWtzIGRhbWViZXP4awo=?= Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: base64 SOVwZXIgZHUga29tbWVyIHNuYXJ0Cg==
Extensions have been defined to negotiate an 8-bit transfer channel over SMTP, but these have not seen wide deployment; the hampering issue is the question of what to do when you have an 8-bit message and a 7-bit channel; downgrading MIME into 7bit using quoted-printable is possible, but not completely straightforward; downgrading a non-MIME message to 7bit is an exercise in guesswork.
Still, the MIME extensions have been proven to work in practice for large and growing communities.