Are you sure you're not writing out in some microsoft specific encoding?

Do you have any thoughts about the
best design approach to this intermediate (xhtml) representation to
make output transformation to other targets easiest?

Without having looked in detail at your problem, I wouldn't use xhtml as
an intermediate format. I'd use a custom format designed to exactly
express the semantics that you want to express and I'd have back ends
that go from there to xhtml or latex or wordxml or whatever. Forcing
your intermediate stage to be xhtml and hiding structure in a rather
dubious looking class attribute (is it really OK to have space separated
tokens in a css class?) just makes your non-xhtml back ends harder.

  <title font-weight="bold" font-style="italic">
    <suffix>, </suffix>
  </title>

Incidentally, I'm realizing that XSLT 2.0's unparsed-text() functions
and reg-exp support means that this could theoretically be extended to
handle TeX input documents.

If you want to amuse yourself over the holidays you could try to get a
regexp that would parse enough of tex to understand this (seasonal)
tex (plain tex not latex) document

http://www.ctan.org/tex-archive/macros/plain/contrib/xii.tex

That someone with time on his hands wrote in a former life...