Standard naming silently drops a property's value when another key standardizes to the same name (e.g. author + creator, Title + title)

[matt-edmondson]

What's wrong

NameStandardizer.StandardizePropertyNames (Frontmatter/NameStandardizer.cs, lines 36, 52, 63, 73) writes every renamed property with a plain indexer assignment:

standardizedFrontmatter[name] = property.Value;

There is no check for whether name is already in the dictionary. When two source keys resolve to the same standard name, the later one overwrites the earlier one without any warning.

This is separate from #131 (which is about Aggressive/Maximum merging swapping values). This bug needs no aggressive merging at all:

• Default options (Conservative merge). PropertyMerger.MergePropertyGroup deliberately keeps both keys when their value types differ. The standardizer then collapses them anyway.
• FrontmatterMergeStrategy.None with FrontmatterNaming.Standard. Nothing is merged beforehand, so every alias pair collides.

Reproduction

Run against the current main:

Input	Call	Output	Lost
---\nauthor: Alice\ncreator:\n - Bob\n---\nbody\n	CombineFrontmatter(input) (defaults)	author:\n- Bob	author: Alice
---\nauthor: Alice\ncreator: Bob\n---\nbody\n	CombineFrontmatter(input, Standard, AsIs, None)	author: Bob	Alice
---\nTitle: A\ntitle: B\n---\nbody\n	CombineFrontmatter(input, Standard, AsIs, None)	title: B	Title: A (line 36 lower-cases Title onto the existing title)

In the second row the later key wins. PropertyMerger does the opposite and keeps the first, so which value survives depends on which code path runs.

Why it matters

CombineFrontmatter is meant to normalize a document without losing information. With the default options, a document carrying both author and creator loses its author, and the output gives no sign that anything was dropped.

Suggested fix / acceptance criteria

• In StandardizePropertyNames, only rename a key to its standard name when that name is free, meaning not already in standardizedFrontmatter and not a key that appears later in frontmatter. Otherwise keep the original key unchanged.
• Apply the same guard to the lower-casing branch on line 36.
• The alternative is to send collisions through PropertyMerger's group-merge logic, so the values are combined the same way the merger combines them.
• Add regression tests for all three rows above. Each must keep both values, under their original keys or merged.

[matt-edmondson]

Triage

• Category: Bug
• Priority: High. Property values are silently lost with the default options (author + creator), and the output gives no sign of it.
• Area / suggested owner: NameStandardizer.StandardizePropertyNames (maintainer: matt-edmondson)
• Duplicates / in progress: Not a duplicate, but closely related to Aggressive/Maximum merging swaps the values of two keys that normalize alike (e.g. related / page_related) instead of merging them #131 (Aggressive merging swaps values) and Merge-strategy cache is keyed only on the property name, so an Aggressive run makes a later Conservative run drop properties #130 (the merge-strategy cache drops properties). All three are key collisions or lost values in the normalization pipeline, so it's worth fixing them together with one shared collision rule. No open PR covers it; Recognise frontmatter delimiters only as whole lines at the top of a document #135 is unrelated.
• Notes: Only rename a key when its standard name is free. Apply the same guard to the lower-casing branch. Add tests for the three rows in the issue.

---

Generated by Claude Code