A letter after a digit starts a new word in Title/Pascal/Camel but not in Snake/Kebab: "1st place" → "1St Place", "abc123def" → "abc_123def"

[matt-edmondson]

What's wrong

The converters disagree about where a word starts after a digit:

• IsWordBoundary (CaseConverter/CaseConverter.cs ~L103–122) breaks on letter→digit ("abc123" → "abc 123") but not on digit→letter, so "123def" stays one token.
• ToTitleCase then calls TextInfo.ToTitleCase, which treats a letter that follows a digit as the start of a word and capitalises it.

As a result, Title, Pascal and Camel case put a word boundary after a digit, while Snake, Macro and Kebab case do not. Converting through one form into another changes the words.

Failure scenario (reproduced)

Input	ToTitleCase	ToPascalCase	ToSnakeCase	ToPascalCase().ToSnakeCase()
"1st place"	"1St Place"	"1StPlace"	"1st_place"	"1_st_place"
"abc123def"	"Abc 123Def"	"Abc123Def"	"abc_123def"	"abc_123_def"
"md5hash"	"Md 5Hash"	"Md5Hash"	"md_5hash"	"md_5_hash"
"3d model"	"3D Model"	"3DModel"	"3d_model"	"3_d_model"

"1St Place" is plainly wrong title casing. The round-trip mismatch also means x.ToSnakeCase() and x.ToPascalCase().ToSnakeCase() return different identifiers for the same input.

This is not covered by #75 (spaces before punctuation) or its open PR. That PR still only breaks on letter→digit and does not change how TextInfo capitalises after a digit.

Suggested fix

Choose one rule and apply it in every converter:

• Digit→letter is a boundary: add it to IsWordBoundary, so ToSnakeCase("abc123def") returns "abc_123_def" and matches Pascal.
• Keep "1st" as one word: stop using TextInfo.ToTitleCase for capitalisation, and uppercase only the first code point of each space-separated token.

Acceptance criteria

• "1st place".ToTitleCase() is either "1st Place" or consistently "1 St Place", whichever rule is chosen.
• For the inputs above, x.ToSnakeCase() == x.ToPascalCase().ToSnakeCase(), with tests covering it.

[matt-edmondson]

Triage

• Category: Bug (it also needs a design decision)
• Priority: Medium. Output such as "1St Place" is visibly wrong. Worse for identifier generation, x.ToSnakeCase() and x.ToPascalCase().ToSnakeCase() produce different results, which breaks round-tripping between cases.
• Area / suggested assignee: IsWordBoundary and ToTitleCase in CaseConverter/CaseConverter.cs. Someone needs to choose between the two rules the issue proposes before implementation starts. Suggested for @matt-edmondson.
• Duplicates: None. The issue already explains why ToTitleCase inserts a space before punctuation: "hello, world" → "Hello , World", "don't stop" → "Don 'T Stop" #75 and its PR don't cover this.
• In progress: Touches the same code as open PRs Keep punctuation attached to its word in ToTitleCase #77 (ToTitleCase inserts a space before punctuation: "hello, world" → "Hello , World", "don't stop" → "Don 'T Stop" #75) and Case-map an astral first letter in ToCamelCase and the first-char helpers #76 (ToCamelCase, ToLowercaseFirstChar and ToUppercaseFirstChar leave a first letter outside the BMP unchanged #74), so expect merge conflicts. Sequence this fix after those two land.

Notes: The "keep '1st' as one word" option means removing TextInfo.ToTitleCase. That fits naturally with #76's code-point-aware first-letter mapping.

---

Generated by Claude Code

[matt-edmondson]

Decision (maintainer, 2026-09-28)

• "Keep '1st' as one word": digit→letter is NOT a word boundary. IsWordBoundary keeps breaking on letter→digit only.
• Stop using TextInfo.ToTitleCase. Uppercase only the first code point of each token, so "1st place".ToTitleCase() gives "1st Place", and Title/Pascal/Camel agree with Snake/Kebab/Macro.

Next reader: replace the TextInfo.ToTitleCase call with first-code-point capitalisation, which fits the code-point-aware mapping from #76. Add tests that x.ToSnakeCase() == x.ToPascalCase().ToSnakeCase() for "1st place", "abc123def", "md5hash" and "3d model". Sequence this after the open PRs touching IsWordBoundary/ToTitleCase.

---

Generated by Claude Code