GetTargetPlatformIdentifier vs TargetPlatformIdentifier conditions

Based on @terrajobst's [proposal](https://github.com/dotnet/msbuild/issues/5171#issuecomment-597422462) which was implemented with .NET 5, I see a behavior difference when calling the `GetTargetPlatformIdentifier('$(TargetFramework)')` function or when using the `$(TargetPlatformIdentifier)` property:

```xml

net6.0-windows;net6.0;net48

$(DefineConst);TargetsAnyOS

```

Reason for that is that msbuild defaults the `$(TargetPlatformIdentifier)` property to "windows" for any tfm older than net5.0 (.NETFramework, .NETStandard, .NETCoreApp <= 3.1): https://github.com/dotnet/msbuild/blob/de1d7a295d709c3a748cc46cd5dc9bddd624ea46/src/Tasks/Microsoft.Common.CurrentVersion.targets#L90

1. Is it possible to disable setting a default "windows" `TargetPlatformIdentifier` (via the `_EnableDefaultWindowsPlatform` property) or does nuget/msbuild heavily rely on it being set? Asking for .NETStandard and .NETFramework tfms which based on their alias representation (`net48` and `netstandard2.0` vs `net5.0-windows`) don't include a platform.
2. What is the official guidance around platform conditions? Should items call into the `GetTargetPlatformIdentifier` intrinsic function or use the `TargetPlatformIdentifier` property instead? In large projects with different platforms like in dotnet/runtime, would multiple `GetTargetPlatformIdentifier` invocations slow down the project's evaluation performance?
3. When conditionally setting a property inside the project file based on the platform, the `GetTargetPlatformIdentifier` function must be called as the `TargetPlatformIdentifier` property isn't available at that time. Isn't it super confusing that ie `net48` returns an empty result when calling the function but "windows" when reading form the `TargetPlatformIdentifier` property either from an item or from a property inside a target file?

I'm posting this as I stumbled upon this behavior difference while working on https://github.com/dotnet/runtime/pull/64500. I'm unsure how to explain to devs on the team why .NETStandard and .NETFramework tfms sometimes have a "windows" platform (when using the TPI property) and sometimes not (when using the TPI function).

@terrajobst @rainersigwald

EDIT:
As an additional note, such a behavior difference is not observable when invoking the `GetTargetFrameworkIdentifier` function and reading from the `TargetFrameworkIdentifier` property.