Following up from #13082 (comment):

On Windows, the .Target property (an ETS property added to FileSystemInfo instances) has always returned a symlink's target as defined in the link itself - which may be a relative or an absolute path.

On Unix, we currently unexpectedly resolve the target path to a full path in .Target, with no ability to inspect the target path as defined.

Note: It would also be convenient to have a separate property that always reflects the full path, irrespective of whether the symlink is defined with a relative or full target path - see #13366.

Steps to reproduce

On macOS or Linux:

Push-Location Temp:/

mkdir -p f$PID

# Define a symlink with  a *relative* target path.
New-Item -Type SymbolicLink f$PID_L -Target ./f$PID

# Querying .Target should return the target path *as defined*.
(Get-Item f$PID_L).Target | Should -Be ./f$PID

Remove-Item -Recurse f$PID, f$PID_L; Pop-Location

Expected behavior

The test should succeed.

Actual behavior

The test fails, because the target path is returned not as defined, but as a full path.

Environment data

PowerShell Core 7.1.0-preview.5