@copilot please invoke the code-review skill and post the analysis/results as a comment on this PR

🤖 Copilot Code Review — PR #113289

Holistic Assessment

Motivation: This implements approved API JsonNamingPolicy.PascalCase and JsonKnownNamingPolicy.PascalCase = 6. The API went through formal review and was approved.

Approach: Generalizes the existing JsonSeparatorNamingPolicy tokenizer (used by snake_case/kebab_case) to support PascalCase via a WordCasing enum and nullable separator. This keeps the word-boundary detection logic shared across all separator-based policies rather than duplicating it, which is the right design.

Summary: ⚠️ Needs Human Review. The implementation is correct, clean, and consistent with the existing codebase. There are a couple of design items a human reviewer should weigh in on (the abstract class that could be sealed, and the class naming).

Detailed Findings

✅ API Surface — Matches approved proposal exactly

• JsonNamingPolicy.PascalCase static property and JsonKnownNamingPolicy.PascalCase = 6 match the approved API.
• Ref assembly is alphabetically sorted (PascalCase between KebabCaseUpper and SnakeCaseLower). ✓
• XML doc comments follow the established pattern ("Returns the naming policy for PascalCasing."). ✓

✅ Source Generator Integration — Correct

• Both the emitter (FormatNamingPolicy switch) and parser (JsonKnownNamingPolicy → policy instance mapping) correctly handle the new enum value. The switch expressions have _ => null defaults, so unknown values are handled gracefully. ✓

✅ Implementation — JsonSeparatorNamingPolicy generalization

The generalization is well done:

• WordCasing enum replaces the bool lowercase parameter cleanly.
• The existing (bool lowercase, char separator) constructor is preserved for backward compatibility with existing subclasses (snake/kebab).
• New (WordCasing) constructor uses Debug.Assert(wordCasing is WordCasing.PascalCase) to enforce that it's only used for the separatorless case.
• The ConvertNameCore logic correctly applies PascalCase casing: uppercase at word boundaries, lowercase elsewhere for uppercase letters; uppercase at word starts for lowercase letters.
• The char? separator correctly handles null by simply not emitting a separator between word groups.

✅ Test Coverage — Comprehensive

• ToPascalCase in NamingPolicyUnitTests.cs has 60+ test cases covering initialisms (XMLHttpRequest, IO, AI), numeronyms (i18n, A11y, k8s), Unicode (surrogates, non-ASCII), whitespace handling, special characters, mixed casing, and boundary strings.
• PascalCase_ConvertName in JsonNamingPolicyTests.cs is now a 6-case smoke test consistent with the other policies' patterns.
• PropertyNameTests.cs includes PascalCase in the JsonSeparatorNamingPolicyInstances test data. ✓

💡 Suggestion — Class naming: JsonSeparatorNamingPolicy

The class is now used for PascalCase which has no separator, making the name JsonSeparatorNamingPolicy slightly misleading. A name like JsonWordBoundaryNamingPolicy might be more accurate. However, this is an internal class with no public API surface, and renaming it would expand the diff scope beyond the PR's purpose. Fine to leave as-is or address in a follow-up.

💡 Suggestion — abstract vs sealed on JsonSeparatorNamingPolicy

JsonSeparatorNamingPolicy is internal abstract with ConvertName sealed. All subclasses (JsonPascalCaseNamingPolicy, JsonSnakeCaseLowerNamingPolicy, etc.) are thin wrappers that only call the base constructor. The abstract modifier exists solely to prevent direct instantiation. This is fine and consistent with the existing pattern pre-PR.

✅ No behavioral changes to existing policies

The existing (bool lowercase, char separator) constructor path is unchanged. Snake_case and kebab_case policies pass through the same code paths as before. The WordCasing.LowerCase/UpperCase branches in the switch expressions produce identical results to the previous lowercase ? ... : ... ternary. Verified by examining the ConvertNameCore method — the PascalCase branch is only taken for the new WordCasing.PascalCase value.

Hello in description I see this conversion:
double space -> DoubleSpace

but in tests
[InlineData("I Phone", "i Phone")]

Is it expected behavior with spaces?

Also, what is the intension of JsonNamingPolicy -- is it rules how properties converted to strings, or how strings converted to properties? If second, I will expect that all other naming polices will be converted to PascalCase, because currently they are converted from PascalCase (default C# naming convention) to specific one. As example - TempCelsius -> TEMP_CELSIUS (Pascal to Snake). So if some client will send any policy, it will be converted to PascalCase and properly handled Any_Naming-FromClient -> AnyNamingFromClient.

Question about implementation, why did you choose this approach -- adding fake separator to JsonSeparatorNamingPolicy instead of direct inheritance from JsonNamingPolicy like it was done by human #100017