Packaging: Would it be possible to use a custom location for dotnet SDK runtimes and versioned components?

[xgqt]

Would it be possible for dotnet to detect SDKs installed in different directories?
I had a look at the dotnet-sdk structure (as provided in precompiled apckages)
and I'm a bit skeptical but maybe there is a solution I am not aware of.

With new way that we want to introduce in Gentoo Linux each dotnet-sdk is
installed into its own directory inside /opt and the users switch between
the /usr/bin/dotnet command with an utility called eselect.

So, do you think this can be resolved by merging all dotnet-sdk installs?
But what "dotnet" exe would we use then?

Please see the issue on the Gentoo bug tracker for additional context:
https://bugs.gentoo.org/882569

Showcase / Details

With the new way of managing dotnet-sdk packages
we want to use the standard Gentoo way of using eselect
(https://wiki.gentoo.org/wiki/Eselect) to select the system-wide
.NET version that would be default when running non-version-bound .NET apps
and would be the default version the user will interact with.

Each SDK is installed into its own directory inside /opt so there is no way
a SDK 7.0 knows about SDK 6.0 location.
The "dotnet" command from a given .NET prefix is linked to
dotnet<BINARY>-<VERSION>.
The BINARY describes whether the SDK is the one built by the user system
or installed from official package.
The VERSION is the major.NET SDK version.

So, a dev-dotnet/dotnet-sdk-bin-7.0.201 package will install
/opt/dotnet-sdk-bin-7.0 and /usr/bin/dotnet-bin-7.0

$ dotnet-bin-6.0 --list-sdks    
6.0.404 [/opt/dotnet-sdk-bin-6.0/sdk]
$ dotnet-bin-7.0 --list-sdks
7.0.201 [/opt/dotnet-sdk-bin-7.0/sdk]

The user will may then use eselect dotnet to switch between the
system-wide selection of the SDKs.

$ eselect dotnet list 
  [1]   dotnet-bin-6.0
  [2]   dotnet-bin-7.0 *
$ eselect dotnet show
dotnet-bin-7.0
$ ls -lah /usr/bin/dotnet
lrwxrwxrwx 1 root root 14 02-16 01:39 /usr/bin/dotnet -> dotnet-bin-7.0

So as you cna see with this approach dotnet is actually one of either
dotnet-bin-6.0 or dotnet-bin-7.0, so there is no way one would be
picked up by the other.

Expectations

dotnet-bin-7.0 --list-sdks executed on SDK 7.0
(installed in /opt/dotnet-sdk-bin-7.0)
picks up components from 6.0 (installed in /opt/dotnet-sdk-bin-6.0).

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.