Good question — that is exactly where tools like this either become useful or fall apart.

For DOM changes, I try not to couple the parser too tightly to fragile selectors. The extraction layer leans more on structural patterns in the rendered chat tree, and I keep the export pipeline separate from the Gemini-specific parsing so I can update that layer without rewriting the whole exporter.

For tricky formatting cases:

nested markdown is normalized into an intermediate representation first, then mapped to Word, PDF, Google Docs, or Notion

code blocks are preserved as their own block type so they do not get flattened into regular paragraph text

large tables are probably the weakest area right now, especially when Gemini renders them inconsistently or with wrapped cells

I am also building a small regression set from real chats, so when Gemini changes something in the UI I can catch breakage faster instead of fixing issues one by one.

Still early, so I would not claim every edge case is solved yet. The goal is to fail gracefully: preserve the content first, then keep as much structure as possible.

If you have a nasty sample with nested markdown, wide tables, or code-heavy output, I would genuinely love to test against it.