When a style doesn't have explicitly defined font, the font from the default character properties (\defchp) is used when present. Instead, the font used for the style should be the default font for the document, defined with \deffN tag.
The same issue occur when the doesn't contain \defchp at all. In this case, the font for the style is not imported, but instead the defined with  \deffN tag should be used.

The construction is not common, and MS Word for example doesn't produce such documents.

When a paragraph has defined tab stops in its style and has the same tab stops locally cleared, the tab stops are still respected when exporting to PDF. Instead, cleared tab stops should not be respected.

Workaround:
Copy the default styles after the Mail Merge

RadFlowDocument merged = sourceDocument.MailMerge(mailMergeSource);
merged.DefaultStyle.ParagraphProperties.CopyPropertiesFrom(sourceDocument.DefaultStyle.ParagraphProperties);
merged.DefaultStyle.CharacterProperties.CopyPropertiesFrom(sourceDocument.DefaultStyle.CharacterProperties);

If the value from the source contains new lines, they should be inserted in the resulting documents as new paragraphs.

The <font> tag has a 'size' attribute that can be set to a number from 1 to 17. This is currently not supported and is just ignored.

CSS style property with a numeric value will not be imported from HTML when the unit type is not specified. Example: .td{padding-bottom: 200;}

This is invalid according to the HTML spec (value is optional only after 0), though web browsers and MS Word open such HTML's correctly.

In specific situations, a paragraph in a table cell which is last on a document page is not exported to the PDF document.
Possible workaround is adding a new paragraph to the last table cell before exporting the document.
For instance:
BlockCollection footerContent = this.document.Sections.First().Footers.Default.Blocks;
Table footerTable = footerContent.First() as Table;
footerTable.Rows.Last().Cells.First().Blocks.AddParagraph();

Import styling properties from HTML for elements without DocumentElementProperties. For example, for ImageInline: the image has width and height and currently they could not be applied through CSS styling as the styling mechanism works only for document elements with DocumentElementPropertiesBase (RadFlowDocument, Section, Table, Paragraph, etc.)

Implement API allowing to add watermarks without specifying its width and the height. The size could be automatically calculated using the text, its font size and font family.

The text of the watermark is exported with the default font family due to incorrect escaping while writing the OpenXML.

Field code fragment is added to the result fragment and exported to PDF/HTML format. The problem is observed when the code fragment is divided into multiple inlines.

For example we have PAGE field. If 'A' is bold we would have 3 inlines (runs) in the instruction text and the issue would be observed.

An empty paragraph is exported with different font size than the one coming from its style. The character properties should come from the style system.

Workaround: Add at least one space in each empty paragraph.

TC field has special tag - \tc, which is currently not supported and is skipped during import. Because of this, the argument of the field, which is hidden in MS Word, becomes part of the document content.

Implement import and export of bookmarks to HTML format.

When creating a field with local run properties, those properties are not applied to the field characters and they are left with the default properties.

Add support for the <w:sym /> element, e.g.:

<w:r>
   <w:sym w:font="Wingdings" w:char="F0FC"/>
</w:r> 


From the specification:
"This element specifies the presence of a symbol character at the current location in the runs content. A symbol character is a special character within a runs content which does not use any of the run fonts specified in the rFonts element (17.3.2.26) (or by the style hierarchy).

Instead, this character shall be determined by pulling the character with the hexadecimal value specified in the char attribute from the font specified in the font attribute."

Currently such symbols are skipped during DOCX import.

Possible workaround: These tags are inserted from MS Word when the Symbol dialog in used. If the document is created with MS Word, the user could insert the symbol using the keyboard, in this case the character is inserted as a normal run.