Roslyn is responsible for populating the individual diagnostics and source generators under an analyzer node. In a multi-targeting case, we have logic that attempts to walk up the hierarchy of nodes to figure out which TFM is active. For example, consider this screenshot:

The "SampleSourceGenerators" node is produced by CPS. Roslyn then walks up that node and finds the netcoreapp3.1 node, which has some special capabilities, namely a capability that starts with $TFM: -- that is then used to figure out which TFM we're looking under.

Looking at the Roslyn code however, I'm guessing this has been broken since we removed the IVsHierarchy wrappers around each target a long time ago. The problem is we may know which TFM we're looking at, but we have no way to figure out which IWorkspaceProjectContext this actually matches. The code currently looks at each IVsHierarchy for our project, and asks the IVsHierarchy for it's TFM. That works if we had separate IVsHierachies for each TFM but we don't (and we shouldn't...getting rid of that code was good.) Right now you'll see the feature work in one of the targets under Dependencies simply because when you ask an IVsHierarchy that multi-targets for it's TFM, you just get the first one.

Note the user impact here is worse now -- previously this only meant you couldn't browse diagnostics provided by an analyzer. This is also where we're showing documents from source generators, so you can't browse to other options.

My proposal is the project system should, rather than giving the $TFM: capability, give some capability that is:

1. The ID directly obtained from IWorkspaceProjectContext.Id that matches up to the Roslyn project created for that node. This means we could just match things directly. Note this option though presumes that the capabilities of a node can change if the design time build triggers a project reload.
2. The unique name given to IWorkspaceProjectContextFactory.CreateProjectContext(). This will be stable; there's also precedent for this being exposed as VSHPROPID_ActiveIntellisenseProjectContext from the IVsHierarchy. Risk here is if the name has spaces, since I guess capabilities can't have spaces?

Otherwise we need some way to directly be told the TFM for a project, but I don't like binding directly to TFM here since that will require this to be redesigned again if we ever have multiple Roslyn projects for the same TFM, say if we ever do the work to expose both debug/release, etc.