What's wrong
In FindBasicCanonicalName (Frontmatter/PropertyMerger.cs, around lines 219–233), the exact-normalized-match loop maps each key to the other key in its equivalence class. With related and page_related:
related → page_relatedpage_related → related
MergeSimilarProperties then groups by canonical name and gets two single-key groups instead of one merged group. MergeArrayValues (around line 189) writes each group under the other key's name.
Failure scenario (reproduced in a fresh process)
input = "---\nrelated:\n- a\npage_related:\n- b\n---\nBody\n"
SortAndStandardize(input, AsIs, AsIs, Aggressive)
Output: page_related: [a] and related: [b]. The values are swapped, and nothing is merged.
With scalar values the two keys never merge either. So for this whole class of keys, the documented Aggressive/Maximum behaviour (merging redundant properties) does nothing, and for lists it corrupts which value belongs to which key.
Suggested fix
Pick one deterministic canonical name per equivalence class, so that every key in the class maps to the same target. For example:
- use the known mapping if there is one;
- otherwise use the unprefixed or shortest key;
- break any remaining tie ordinally.
As a safety net, a group with a single original key should keep that key's own name.
Acceptance:
- the input above produces a single
related: [a, b], or whichever canonical name is chosen, with both values;
- a test covers the scalar case too.
What's wrong
In
FindBasicCanonicalName(Frontmatter/PropertyMerger.cs, around lines 219–233), the exact-normalized-match loop maps each key to the other key in its equivalence class. Withrelatedandpage_related:related→page_relatedpage_related→relatedMergeSimilarPropertiesthen groups by canonical name and gets two single-key groups instead of one merged group.MergeArrayValues(around line 189) writes each group under the other key's name.Failure scenario (reproduced in a fresh process)
Output:
page_related: [a]andrelated: [b]. The values are swapped, and nothing is merged.With scalar values the two keys never merge either. So for this whole class of keys, the documented Aggressive/Maximum behaviour (merging redundant properties) does nothing, and for lists it corrupts which value belongs to which key.
Suggested fix
Pick one deterministic canonical name per equivalence class, so that every key in the class maps to the same target. For example:
As a safety net, a group with a single original key should keep that key's own name.
Acceptance:
related: [a, b], or whichever canonical name is chosen, with both values;