Honestly I'm not in favor of this change. While the current layout might not be correct in all cases, it existed for years and works. I fear that many repositories (150+ repos depend on Arcade) expect the dotnet installation to exist in the current location.

Another example is

This is enabled with repo sets DOTNET_USE_ARCH_IN_INSTALL_PATH, as discussed in the issue.

We also have DOTNET_INSTALL_DIR support, so it's not the only different path in these scripts.

Right, but I question the benefit of adding yet another path. I'm not sold that this is needed. Which repositories would set this?

This enabler is mainly for runtime where we do a lot of platform-specific builds, I'm testing it dotnet/runtime#104295 to see how CI reacts.

BTW, we don't have to set it repo-wide either. Just having this facility enables the consumer (either the repo itself, or someone building a repo) to use the derived RID in installation path that works with dotnet.sh/cmd.

After thinking through this some more I'm also not sure anymore this is the best approach since it's only really useful if we enable it by default and we probably don't have the resources to fix all the cases where we assume the current path.

I had another simpler idea though: we should be able to detect whether we have the right dotnet by running e.g. .dotnet/dotnet --version in InitializeDotNetCli and if it doesn't work we could delete and redownload it. That'd leave the path unchanged. @ViktorHofer what do you think?

Re-downloading the right RID can be nice - when jumping locally between Windows and WSL, you need to keep nuking the .dotnet dir (dotnet--version does not even run though).

Alternatively, why not just adding an optional argument with the destination dir and override it in runtime's scenarios?

when jumping locally between Windows and WSL, you need to keep nuking

You can work around this by installing the right .NET SDK in a global location on both systems. These scripts are able to auto-detect that you have the right version available and skip downloading the repo-local copy.

Another example is

arcade/src/Microsoft.DotNet.Arcade.Sdk/tools/RepoLayout.props

Line 24 in 48f3eaf

<DotNetRoot Condition="'$(DotNetRoot)' == ''">$([MSBuild]::NormalizeDirectory('$(RepoRoot)', '.dotnet'))</DotNetRoot>

It will not fail with the current state of this PR because of line 22. DOTNET_INSTALL_DIR is set by the script and we don't hit this path when tools.ps1/sh are involved. If we have another example where DOTNET_INSTALL_DIR is not honored, it is likely a bug which that needs fixing. I covered the ones in runtime dotnet/runtime#104295.

IMO we should take this change and fix like those few places taking wrong assumptions and there aren't that many. I think this change is even less riskier than any other change we make in arcade which can break downstream, in that we have it behind an enviornment variable, which we can remove if we want after updating all consumer repos to use the new scheme.