I guess we can add more tests while working on V2 JSON serializer. So I will keep this open some time.

If there are duplicates we could simply add comments in existing tests to describe additional scenarios are tested. If we can not create clear comments please keep duplicate tests.

@iSazonov Sorry for the initial submission with redundant tests. I've refactored based on your feedback:

Removed (covered by existing tests):

• null, arrays, hashtable (lines 94-107)
• Depth, AsArray, Multiple pipeline (lines 43-77)

Consolidated into TestCases format:

• Enum: default + -EnumsAsStrings
• EscapeHandling: EscapeHtml + EscapeNonAscii

Kept:

• Uri, Nested PSCustomObject (renamed), EscapeHandling default (renamed), Depth over 100 error

Added:

• Special floating-point values (Infinity, -Infinity, NaN)
• Empty array ($null)
• SwitchParameter ({"IsPresent":true/false})

Result: +29/-51 lines, removing redundancy while improving edge case coverage.

I'll add more test cases if I find other scenarios worth covering while working on V2 improvements.

@yotsuda Have we tests to cover all code paths for if (currentDepth > context.MaxDepth)? Notice, we don't add extended/adapted properties if isPurePSObj = true; and add otherwise.

@iSazonov Added tests covering both code paths for currentDepth > context.MaxDepth (b10f8be):

1. Pure PSObject (isPurePSObj = true): AddPsProperties returns early without adding ETS properties. The ToString() result is used as-is.
2. Non-pure PSObject (isPurePSObj = false): AddPsProperties processes ETS properties on the string-converted value.

# Pure PSObject - depth exceeded (isPurePSObj = true)
$pso = [PSCustomObject]@{ Name = 'test' }
$pso | Add-Member -NotePropertyName ETSProp -NotePropertyValue 'ets'
@{ inner = $pso } | ConvertTo-Json -Depth 0 -Compress
# Output: {"inner":"@{Name=test; ETSProp=ets}"}

# Non-pure PSObject (Version) - depth exceeded (isPurePSObj = false)
$version = [version]'1.2.3'
$version | Add-Member -NotePropertyName ETSProp -NotePropertyValue 'ets'
@{ inner = $version } | ConvertTo-Json -Depth 0 -Compress
# Output: {"inner":"1.2.3"}

Also added a comparison test for pure PSObject serialization within depth limit.

Also fixed the DateTime ETS test (f3025f7) to use UTC, avoiding timezone conversion issues that caused intermittent failures.

@yotsuda Thanks! I see if object is pure PSObject LanguagePrimitives.ConvertTo() does all work and add ETS properties so we skipp AddPSProperty(). But I wonder why these properties are not added if isPurePSObj == false - I'd expect AddPSProperty() should add. Thoughts?

@iSazonov Let me trace through the code flow (referring to V1/JsonObject.cs).

When isPurePSObj == false and currentDepth > MaxDepth:

1. The object is converted to string via LanguagePrimitives.ConvertTo(obj, typeof(string), ...) (line 618-619)
2. AddPsProperties is called with the converted string
3. Since isPurePSObj == false, we don't early-return at line 671-673
4. The string is wrapped in a new Dictionary with key "value" (line 680-682)
5. AppendPsProperties is called (line 685)

In AppendPsProperties:

• Line 710-712 checks if the original psObj.BaseObject is string or DateTime - if so, it returns early (no ETS properties added)
• Line 716-719: Since isCustomObj == false, only Extended properties are searched (not Adapted)
• Any Extended properties found are added to the dictionary

After AppendPsProperties returns:

• Line 687-690: If the original rv was not a dictionary and no properties were added (dict.Count == 1), the original string is returned instead of the dictionary wrapper

So the ETS properties are added for isPurePSObj == false when:

• The original BaseObject is not string/DateTime, AND
• Extended properties exist on the PSObject

The properties are not added when:

• BaseObject is string/DateTime (intentional, these types use their natural serialization)
• No Extended properties exist

Note for #26654 (V2/STJ): While testing this, I found an issue in WriteProperty where MaxDepth == 0 directly called ToString() without going through WriteDepthExceeded, so ETS properties on nested PSObjects were not included. I've fixed this in #26654 (commit 67a1bbd) and added a test to cover this case.