Verified today (2026-08-29): this no longer reproduces.
The root cause was in XWiki Rendering, exactly as diagnosed in the comments above — each audience section is parsed in its own context, so the IdGenerator was not aware of the headings rendered before it. That is XRENDERING-6 ("Id are not unique when included document or macro content has the same headers as the top document"), closed as Fixed in 13.10.4 and 14.2-rc-1. Its closing comment covers this case explicitly: "The same issue also exists for macro contents as they are parsed separately."
Checked on the live pages:
ReleaseNotes/Data/XWiki/9.6RC1 (the example given in this issue): the two "Miscellaneous" headings now get HMiscellaneous and HMiscellaneous-1, and there is no duplicate heading id anywhere on the page.
ReleaseNotes/Data/XWiki/14.10: the three sections generated by the releasenotechanges macro get HMiscellaneous, HMiscellaneous-1 and HMiscellaneous-2 in document order (For Users / For Admins / For Developers), and every TOC link matches its heading one-to-one.
Nothing needs to change in the Release Notes application itself — it only ever needed a rendering engine that shares the IdGenerator across macro content. The application's minimum supported XWiki version is 14.10, which is above both fix versions, so there is no supported range left in which this can happen.
RN-44 is a duplicate of this issue (same symptom, same cause); its example page 11.1RC1 also renders correct unique anchors today.
Proposing to close this issue as Fixed.
Vincent Massol on 29/Aug/26 00:34
Verified today \(2026\-08\-29\): this no longer reproduces.
The root cause was in XWiki Rendering, exactly as diagnosed in the comments above — each audience section is parsed in its own context, so the IdGenerator was not aware of the headings rendered before it. That is XRENDERING\-6 \("Id are not unique when included document or macro content has the same headers as the top document"\), closed as Fixed in *13.10.4* and *14.2\-rc\-1*. Its closing comment covers this case explicitly: _"The same issue also exists for macro contents as they are parsed separately."_
Checked on the live pages: * [ReleaseNotes/Data/XWiki/9.6RC1|https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/9.6RC1] \(the example given in this issue\): the two "Miscellaneous" headings now get {{ HMiscellaneous}} and {{ HMiscellaneous\-1}}, and there is no duplicate heading id anywhere on the page. * [ReleaseNotes/Data/XWiki/14.10|https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/14.10]: the three sections generated by the {{ releasenotechanges}} macro get {{ HMiscellaneous}}, {{ HMiscellaneous\-1}} and {{ HMiscellaneous\-2}} in document order \(For Users / For Admins / For Developers\), and every TOC link matches its heading one\-to\-one.
Nothing needs to change in the Release Notes application itself — it only ever needed a rendering engine that shares the IdGenerator across macro content. The application's minimum supported XWiki version is 14.10, which is above both fix versions, so there is no supported range left in which this can happen.
RN\-44 is a duplicate of this issue \(same symptom, same cause\); its example page 11.1RC1 also renders correct unique anchors today.
Proposing to close this issue as Fixed.
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.
