Die TOC-Komponente generiert id-Attribute für Header-Elemente basierend auf dem Header-Text.
Hier ist beispielsweise ein Header.
main outlet
Der Abstand ergibt sich aus den Stilen, die auf #main-outlet angewendet werden, einem Discourse-App-Element, das nichts mit diesem Beitrag zu tun hat.
Das ist nicht das Ende der Welt, wenn ich eine alternative id für den Header angeben könnte. Die TOC-Komponente unterstützt dies:
https://github.com/discourse/DiscoTOC/blob/master/common/header.html#L293
Leider entfernt Discourse id-Attribute von Beitrags-Elementen, bevor der oben genannte Code ausgeführt wird, sodass die Logik blockiert wird.
Hier ist ein Header, der <h4 id="alt-main-outlet">main outlet</h4> verwendet:
main outlet
Beachten Sie, dass er immer noch main-outlet anstelle von alt-main-outlet verwendet.
Ich vermute, Discourse macht dies in der Erwartung, dass jemand ein Seitenelement manipuliert. Aber mit der TOC-Komponente lässt sich dies leicht umgehen.
Wenn es eine Lösung dafür gibt oder dies ein bekanntes Problem ist, das ich übersehen habe, bitte ich um Entschuldigung für die nachfolgenden ungefragten Meinungen 
P.S.
Persönlich finde ich, dass Discourse Element-id-Attribute NICHT entfernen sollte. Dies ist eine grundlegende Webseitensstruktur und wird für die Seitennavigation mit URL-Fragmenten verwendet. Wenn jemand einen Link zu einem Element in einem Beitrag erstellen möchte, halte ich das für das Recht des Autors.
Die Tatsache, dass TOC ID-Manipulationen ermöglicht, deutet darauf hin, dass diese Maßnahme des ID-Entfernens grundsätzlich entfallen könnte.
Wenn das Discourse-Team so besorgt über ID-Hijacking ist, sollten alle Discourse-IDs präfixiert werden, z. B. discourse-main-outlet, und das Entfernen von IDs sollte nur auf diese präfixierten IDs angewendet werden.
Ich kann die Unmöglichkeit dies angesichts des bestehenden Codes nachvollziehen!
Man könnte sich eine Reihe von ausgeschlossenen IDs vorstellen (z. B. main-outlet, etc.), die entfernt werden. Dies löst zwar immer noch das Problem, dass TOC verwendet wird, um diese Sicherheitsmaßnahme zu umgehen, aber es würde Autoren zumindest erlauben, nützliche Anker zu erstellen.
P.P.S.
Direkt damit verbunden ist das Problem von Headern mit demselben Textinhalt.
Topic One
Examples
Topic Two
Examples
Mit TOC erhalten beide Examples-Header dieselbe ID, was offensichtlich stark fehlerhaft ist. TOC könnte inkrementierende Indizes anhängen (z. B. examples, examples-2, usw.) – und dies sollte wahrscheinlich standardmäßig geschehen – aber besser wäre eine Lösung für das oben diskutierte Problem, die Autoren die Möglichkeit gibt, ihre Inhalte selbst zu beschreiben. Z. B. <h5 id="topic-one-examples">Examples</h5>, usw.