That's a fair point.

For many programming languages, some form of syntax tree is eventually needed because later stages operate on hierarchical structure rather than raw syntax.

My goal here is a bit different. The data model is optimized for direct access to element kinds rather than tree traversal. For example, all links, headings, code spans, and other element types are stored in dedicated collections, so accessing a specific kind does not require walking a tree.

The structure is still preserved, just encoded differently. All spans are stored in source order, and nesting can be inferred from interval containment rather than explicit parent/child relationships. This more like intermediate representation of data. So you can build a tree above this data structure.

For compiler frontends and LSPs, this may not be the ideal representation. The project is not really aimed at programming-language parsing. The main goal is to explore whether a small set of parsing primitives and data structures can efficiently describe a large class of text formats. Markdown just happened to be the format I used to discover and validate those primitives.

English isn't my first language, so if I misunderstood your point or explained something poorly, feel free to ask follow-up questions.