TML looks quite nice, especially in its style-sheet aspect. 
(Incidentally, this is very different from my reaction to 
the underlying MOM, whose prominent tags and copious manual
are not to my taste.)

I would truly welcome TML if it could feed multiple back ends.
Journals typically accept papers in only a few formats. I
have encountered requirements for Word or rtf and Latex, with
per-journal style sheets. It's always a huge chore to adapt
a groff document to their conventions. If you can make it
easy to choose the journal *after* the paper is written,
you've got a winner. Otherwise, I suspect TML has a tough
row to hoe among ingrained competitors.

Doug

General questions and comments

Are such things as these in prospect?

    automatic sequence numbers (not just on lists)
    cross referencing
    indexing
    graphics inclusion, scaling and text wrapping
    keeps and floats
    captions
    multicolumn pages
    formal syntax (see 1.1 below)

It looks as if one could easily introduce new {...} categories
on the fly, at least if they only use standard attributes
such as font, indent and numbering. If true, that's very cool, and perhaps
answers the "captions" item above. 

Lists are well on the way to tables. Do you expect to handle more
general tables? (Though I think tbl should be on the table, so to
speak, it would be reasonable to adopt pic and eqn verbatim.)

I'm not sure I agree that there's merit in all end tags being the
same. Parenthesis-counting is not always fun. TML's convention that
blocks be strictly nested could be imposed on labeled ends, too,
with a labeled end closing all smaller open blocks. 

Nitpicking

1. \E seems incongruent with the rest of TML syntax. I'm guessing
    that its upper case is MOM's underwear showing.

1.1 I am always uneasy about a language unless I have a formal
    grammar at hand. Definition by example is not enough to
    resolve subtle questions.  Examples: must [...] tags be
    bunched immediately after {...} or can they come anywhere
    in text? What is the scope of {document} and of the attributes
    that come with it? (How would one specify authorship in a
    book with an editor and different authors per chapter? Can
    chapter authors be automatically shown in TOC entries?)

    I first assumed that #dimensions is a comment, but then
    #left and #right revealed otherwise. Now I don't know
    whether #dimensions can be omitted

    I did not see a general statement about metacharacters,
    in what contexts they are special, and how to quote them
    when necessary.

1.2 How do you "force" an even page (e.g. for a two-page spread)?

    I hope you have been able to hide groff's crazy convention
    that requires setting  paper size on the command line (in
    an awful syntax) as well as in markup.

1.4 Hyphenate-page-numbers is awfully special. How do you get
    other formats, e.g. "12-3" for within-chapter numbering,
    or "Page 1 of 3"?  Why should style indicators for
    sequence numbers differ among pages, chapters, lists, ...?
    A similar question holds for cross-references, e.g. 
    how at one stroke could one switch every textual cross
    reference between section number and page number?

2. Is the indent for an epigraph or quote applied at left margin,
    right margin, or both? 

    How would one specify style for the attribution line in an epigraph?
    (Is that a use for epigraph-block, for which no distinctive purpose
    is revealed.)
    
    Misspelling: statr => start

    As I read the description, one gets a new paragraph whenever an input
    line begins with p. This cannot be what you meant. The examples show .p,
    which is just as bad because it would, for example, turn the groff .ps
    request into a paragraph break (since whitespace after p is optional),

    I see from section 2.11 that there is a more natural way to set
    the prefix and enumeration characters. Setting them by "prefix:"
    seems strange. (It could be useful, though, for avoiding ambiguity
    with a prefix like 'A'. 

    Why restrict prefix: and enumeration: to single characters? (Comments
    1.2 and 1.4 also address overly specialized features.)

    The names "prefix" and "enumeration" suggest no relationship between 
    their roles. surely you can find a more congenial pairing, maybe
    label-x, where x is start/end, open/close, or ?something similar.

    The stars in the nested-list example make no sense to me. Are they
    some kind of note to yourself?

5. Kerning seems to be adjustable only locally. In most cases
    wouldn't it be better to address it globally: "In font f
    adjust pair xy by increment i"? Peppering the text with
    kern notes forecloses style changes.

6. Presumably alias replacement can go to arbitrary depth. I hope there
    is no requirement that aliases be defined in topologically sorted
    order.

    I didn't understand the patterns for user-defined strings.

    Garbled text: "any instances of anywhere".

    The promised file-inclusion feature isn't here, it's in section 8
    (which is misnumbered 7).