Agreed, this needs to get better. At the very least the error should show that there is a wrapping array as:

Expected @(1, 2, 3), but got @(@(1, 2, 3)).

Or better:

Expected a collection @(1, 2, 3) with length 3, but got a collection @(@(1, 2, 3)) with length 1.

Problem is finding the right balance where this kind output stays readable even for bigger objects. Probably the best approach here is to list the info that stays short on the top and progress to expanding the objects on the bottom.

Expected a collection with length 3, but got a collection with length 1.
Expected:
Type: [Object[]]
Length:  3
Content: 
@(1, 2, 3)

Actual: 
Type: [Object[]]
Length:  1
Content: 
@(
  @(1, 2, 3)
)

I will start with the simplest fix, and solve it better when Assert merges into Pester, because the formatting there is solved better.

This problem should lie in the Format.psm1 module where the formatting is defined.

Format-Collection works as expected, returning @(@(1,2,3)). However these lines are unrolling the outer array.

function ShouldBeFailureMessage($ActualValue, $ExpectedValue, $Because) {
    # This looks odd; it's to unroll single-element arrays so the "-is [string]" expression works properly.
    $ActualValue = $($ActualValue)
    $ExpectedValue = $($ExpectedValue)

Demo:

    It "ISSUE: single element nested array" {
        $a = 1, 2, 3
        ,$a | Should -Be $a
    }

    It "nested arrays" {
        $a = (1, 2, 3),1
        $a | Should -Be (1, 2, 3)
    }

    [-] ISSUE: single element nested array 83ms
    Expected @(1, 2, 3), but got @(1, 2, 3).
    59:         ,$a |Should -Be $a
    at <ScriptBlock>, C:\Users\frode\Git\Pester\debug.tests.ps1: line 59
    [-] nested arrays 35ms
    Expected @(1, 2, 3), but got @(@(1, 2, 3), 1).
    64:         $a |Should -Be (1, 2, 3)
    at <ScriptBlock>, C:\Users\frode\Git\Pester\debug.tests.ps1: line 64

Something like this might work to fix both this issue and the string-specific error message that the lines were there to fix. Looks kinda ugly though...

if(@($ActualValue).Count -eq 1 -and @($ActualValue)[0] -is [string]) { $ActualValue = $($ActualValue) }
if(@($ExpectedValue).Count -eq 1 -and @($ExpectedValue)[0] -is [string]) { $ExpectedValue = $($ExpectedValue) }

During testing I also noticed that this test is passing, bug in ShouldBe/ShouldBeExactly?

It "single element integer" {
        $a = 1
        ,$a | Should -Be $a
}

The problem here is that when you pass an array through the pipeline it enumerates it, but when you wrap the array into an extra array (by using ,) then the pipeline will eat the wrapper array and pass the original array through the pipeline as single item. Inside Should we then check if we got a collection of we got a single item. Non-enumerated array is a single item, so it is not equal to the original array because they have different size.

If we have an array after the pipeline we know that it must have been wrapped (otherwise the pipeline would enumerate it) and so we want to add extra array to the incoming value when it is array and print it via the format collection.

bug in ShouldBe/ShouldBeExactly

The pipeline unrolls the array created by , so single value 1 passes through as single value 1, and 1 is equal to 1. So this works as expected.

1 | foreach { 1 -eq $_ } # -> true 1 = 1
,1 | foreach { 1 -eq $_ } # -> true 1 = 1
,,1 | foreach { 1 -eq $_ } # -> false @(1) != 1