Unable to resolve symbols when additional metadata references are added to the project compilation

[anto-deepsource]

Version Used:
Microsoft.CodeAnalysis.CSharp.Workspaces v4.8.0
Microsoft.CodeAnalysis.Workspaces.MSBuild v4.8.0

In certain cases, I am getting Symbol (semanticModel.GetSymbolInfo(node.Type).Symbol) as null when using v4.8.0 with .NET 8.
The same works fine with .NET 7.

This only happens in .NET 8 when certain additional metadata references are added to the project compilation. Some types that I noticed causing this are:

System.Threading.Thread
System.Buffers.MemoryManager<T>
System.Threading.CancellationToken
System.ThreadStaticAttribute
System.Runtime.CompilerServices.CompilerGeneratedAttribute
System.Runtime.InteropServices.DllImportAttribute
System.Threading.Tasks.TaskContinuationOptions
System.Runtime.InteropServices.DynamicInterfaceCastableImplementationAttribute

When tested with v4.10.0, both .NET 7 and 8 return the Symbol as null.

Steps to Reproduce:

I have created a repo for reproducing this with both .NET 7 and 8:
https://github.com/anto-deepsource/roslyn-symbolinfo-repro

Here, you can notice the Symbol namespacing correctly getting resolved to Sytsem in .NET 7, while the Symbol resolves to null in .NET 8.

1. Open a project and get it's compilation

var project = await workspace.OpenProjectAsync("test-project/test-project.csproj");
var compilation = await project.GetCompilationAsync();

2. Add certain additional metadata references

var metadataReference = MetadataReference.CreateFromFile(typeof(Thread).Assembly.Location);
compilation = compilation?.AddReferences(metadataReference);

3. Get the tree and semantic model

var tree = await doc.GetSyntaxTreeAsync();
var semanticModel = tree != null ? compilation?.GetSemanticModel(tree) : null;

4. Walk the tree and get the symbol info for a node

semanticModel.GetSymbolInfo(node.Type).Symbol

Is there any change in the behaviour causing this difference in different versions of .NET and the packages?
Any help in this regard is appreciated.

[jaredpar]

Moving to runtime because this is more a question about how / why types moved between assemblies from .NET 7 to .NET 8.

My expectation is that they will resolve this as "By Design". The specifics of which types are in which assembly is an implementation detail. Depending on it, as you do by using MetadataReference.CreateFromFile(typeof(Thread).Assembly.Location) is depending on an implementation detail. If the goal is to have a Compilation that can resolve types for .NET 7, 8, etc ... then you need to use the full reference set vs. hand crafting them. Suggest that you use a project like basic-reference-assemblies to do that.