> Making the markup language interchangeable would require limiting each
> at the lowest common denominator.

I don't think this is necessary. Apps can exchange XML data that include
structures they know about and use, as well as structures that they don't
know about. The key is they do not discard things they do no know about, but
pass it along to others.

In Instiki:
Suppose all input formats are converted into some internal XML dialect D.
Each markup format F would have a pair of translators: D->F and F->D.
Translators have to retain D-structures that do not translate to/from F. So
when I am editing in Textile I might see the raw-XML equivalent of some RDoc
structure.

D itself should be extensible. So my format, F, could include semantic
markup like <chapter> and <section>.

HTML presentation should be done by CSS on the underlying representation D,
by default. Assuming semantic markup is allowed in the input formats F (e.g.
<chapter>), the presentation could take advantage of this with <div>,
<span>, fold/unfold, mapping to tables via CSS, etc.

Browser-based editing could be based on the structure (add/delete/edit
nodes), in addition to the usual text-area based editing via some markup F.

Some well-formedness rules may have to be more carefully checked in
translations. But other than this it should work pretty well.