#10641 - The new error formatting is nice but it might have some disadvantages, too.

Demo script

function Test-Error {
    Write-Error @'
Oops, error! Details:
- Somewhat long details line 1, and more somewhat long details line 1.
- Somewhat long details line 2, and more somewhat long details line 2.
'@
}

Test-Error

NormalView error formatting (good old but with some "noise"):

Test-Error : Oops, error! Details:
- Somewhat long details line 1, and more somewhat long details line 1.
- Somewhat long details line 2, and more somewhat long details line 2.
At C:\ROM\z\_191023_233922_ps_ErrorView\bad-error.ps1:11 char:1
+ Test-Error
+ ~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Test-Error

ConciseView error formatting (nice and shiny but with issues):

Test-Error: C:\ROM\z\_191023_233922_ps_ErrorView\bad-error.ps1
Line |
  11 | Test-Error
     | ^ Oops, error! Details: - Somewhat long details line 1, and more somewhat long details line 1. - Somewhat long details line 2, and more somewhat long
     | details line 2.

Some issues

1. The file path and line number are in different places. Even for a human it requires
   some effort to connect them together in order to go to the problem location.
   But it is also the challenge for various error parsers in text editors, log
   parsers, etc. VSCode, for example, understands "standard link" patterns as
   <path>(<line>), <path>:<line> [char:<column>]. Is it going to work well
   with the new ConciseView formatting?
2. Column number is missing. The caret position is shown in a different way,
   this is somewhat fine for humans but programs (VSCode and others) will
   have difficulties with getting this info.
3. Line formatting of error messages is not respected. Yes, in most cases error
   messages are one liners. But lengthy errors with some detailed multiline
   descriptions are not rare, too. Preserving the original formatting of such
   messages would be useful, they were composed in such a way for reasons.
4. When the error caret position is more to the right, the error message first
   line is more indented and gets even more difficult to read for long messages.
   Copying the error messages is also difficult with such extra indentation.

Suggestion

For ConciseView, why not just strip some "noise", i.e. CategoryInfo and
FullyQualifiedErrorId lines and keep the rest just like in NormalView?
Example:

Test-Error : Oops, error! Details:
- Somewhat long details line 1, and more somewhat long details line 1.
- Somewhat long details line 2, and more somewhat long details line 2.
At C:\ROM\z\_191023_233922_ps_ErrorView\bad-error.ps1:11 char:1
+ Test-Error
+ ~~~~~~~~~~

All the above issues are resolved (or at least negative effects reduced).