Interoperable markers for automatic heading numbers

Extensions
1

Can Markdown editors agree on an interoperable convention for identifying persisted, automatically managed heading-number prefixes?

Consider a document containing:

# 1. Introduction
## 1.1 Background
## 1.2 Scope

Some editors can automatically recalculate these numbers when headings are inserted, removed, moved, or assigned a different level.

There are two common implementation approaches:

  1. Generate numbers only when rendering. This keeps the Markdown source clean, but the numbers are missing in editors and workflows that do not support the same extension.
  2. Write the numbers into the heading text. This preserves them across Markdown editors, plain-text tools and exports, but creates a new problem: how can an editor distinguish a managed prefix from intentional content such as 2026 outlook or 10 reasons to use Markdown?

I found several existing approaches in Obsidian plugins:

  • Auto Numbered Headings uses visible numbering patterns without an invisible marker.
  • Auto Heading writes the number into the file and places U+2060 WORD JOINER after the generated prefix.
  • Auto Headings uses U+2060 at both boundaries of the generated prefix, so that one remaining marker can still identify a damaged or partially edited prefix.

This suggests at least four possible conventions:

A.  1.2 Heading
B.  1.2<WJ> Heading
C.  <WJ>1.2<WJ> Heading
D.  No persisted number; use metadata or render-time numbering

Here <WJ> represents U+2060 WORD JOINER.

The marker-based approaches permit deterministic recognition and removal of generated prefixes. However, invisible characters introduce interoperability questions involving search, copy and paste, Git diffs, heading anchors, accessibility, Unicode normalization and conflicts between tools that use the same marker for different purposes.

A convention may eventually also need to support:

  • conventional forms such as 1. Heading;
  • hierarchical forms such as 1.2 Heading;
  • alphabetic and Roman numbering;
  • localized digits and non-Latin scripts;
  • right-to-left and mixed-direction headings;
  • individually numbered and unnumbered headings in the same document.

I am not necessarily proposing that this become part of core CommonMark syntax. I would first like to determine whether a defensible convention already exists, or whether Markdown editor developers would benefit from documenting an interoperable extension.

Questions:

  1. Is persisting generated numbers in heading text a reasonable portability goal?
  2. Is heuristic recognition without a marker sufficiently safe?
  3. If a marker is needed, is one trailing U+2060 preferable to markers at both boundaries?
  4. Should the marker identify only “managed numbering”, or also encode the numbering style or owning implementation?
  5. Would visible heading attributes, document metadata, or another established Markdown extension be more appropriate?
  6. Which compatibility failures should rule out an otherwise workable convention?

I would especially welcome experience from Markdown parser and editor implementers, accessibility specialists, and authors of existing heading-numbering extensions.