I don't believe that the creation of a new content-type is likely to
result in a lot of new mbox readers or writers.
There is however a new issue, viz. that readers and writers are likely
to be on separate systems, with possibly different conventions.
that's not really a new issue, as readers and writers have been on
separate systems for years, for two reasons. one is that mbox is
the closest thing that exists to a de facto standard for exchanging
mail folders between systems or MUAs. the second is that it's been
common for various kinds of systems with different mbox variants to
share a common NFS-mounted mail spool directory.
And I do believe that
whatever new software is written to read or write mbox files will be
similar to existing software that reads and writes mbox files. If most
existing software doesn't need knobs to deal with format variation, I
don't suppose that most new software will need it either.
The UW imap formats document mentioned earlier in this discussion
lists at least 5 distinct flat file formats, identified and parsed
separately, with variations ("knobs") in the two areas already
specifically suggested for parameters, namely separator line format
and line ending conventions.
there's a difference between 5 flat file formats and 5 flat formats that
all happen to resemble mbox. there are other flat mailbox file formats
that are completely different, including MM, BABYL, MMDF, and a couple
of others whose names I don't recall.