I saw that the efforts to enable header IDs for markdown content have been stopped but I am a bit lost with the comment "… summary: we should do it like pandoc does".

Is my understanding correct that fossil's internal markdown renderer does not support header IDs, if I want them for my embedded documentation, I would to have to check in already compiled HTML docs which includes the IDs & table of contents? In other words, I cannot use fossil markdown but have to do the HTML rendering outside fossil. The main disadvantage here is that I have to keep both markdown source and HTML output in the repository.

Did I miss something or are there any better practices for including ToCs in embedded documentation (or wiki pages)?

Is my understanding correct that fossil's internal markdown renderer does not support header IDs, if I want them for my embedded documentation, I would to have to check in already compiled HTML docs which includes the IDs & table of contents?

You do not have to pre-compile the wiki to HTML but you do have to add the anchors and TOC manually. Here's an example:

https://fossil.wanderinghorse.net/r/cwal/info?name=7be761e7448368ae44536cdd6fbe835e1dc83b9c&txt=1

I saw that the efforts to enable header IDs for markdown content have been stopped but I am a bit lost with the comment "… summary: we should do it like pandoc does".

It turns out that dynamically generating headers is far more complicated and nuanced than i initially hoped for when starting that defunct branch. The overall consensus of the linked discussion was essentially that if we're doing to do it right, we should follow pandoc's example. So far nobody has stepped up to implement that, though.

The part of that thread which diverged into pandoc starts at 9d5974ea863904de.

Did I miss something or are there any better practices for including ToCs in embedded documentation (or wiki pages)?

Currently they have to be added by hand, generated via client-provided code before checking in the documents, or generated via client-provided JS code which gets loaded with the site's skin and runs automatically for paths which can render embedded docs. In my own docs they're hand-crafted (like the example lined to above).