I am wondering if it would make sense to call this in SourceModuleSymbol.ForceComplete, for example, after we find this.GlobalNamespace.HasComplete(CompletionPart.MembersCompleted). At this point I think we should have reported declaration diagnostics for all members, and we would know if there are duplicate interceptors for a location.

AddOrUpdate

Is this extension method to provide the NETCOREAPP functionality to non-NETCOREAPP builds? If so, could the entire extension method be wrapped in if !NETCOREAPP?

Other extensions in this file polyfill methods for netstandard2.0 in a similar way. I wanted to be consistent with them.

diagnostics.Add(ErrorCode.ERR_ModuleEmitFailure

It seems unexpected to me for a TryGet() method to report diagnostics. (What if there are multiple calls?) If we have one specific caller where reporting a diagnostic makes the sense (and it looks like we only have one caller currently), would it make sense to simply return the OneOrMany to the caller and have the caller report the diagnostic?

Detecting the problematic condition at the call site would require returning additional information. I think it's fairly common in the compiler to report errors associated with something we are trying to get, for example, with use site diagnostics.

AllNullableIgnoreOptions

Why ignore nullable differences rather than using ObliviousNullableModifierMatchesAny?

We are checking for unsafe nullability differences separately. I decided to just not report on safe nullability differences.

When nullable differences are detected by signatures comparing not-equal like this it's a pain, because the differences might be dynamic/object stuff, or it might be string?/string stuff, which we might want to group separately, so that #nullable disable warnings disables the latter and not the former.

This is why the following "bug" occurs for partial methods. (warning is not reported in SharpLab, you'll have to paste into a new project in VS to reproduce.)

#nullable enable annotations
#nullable disable warnings

public partial class C
{
    // implementation accepting "less" than definition is unsafe, and we don't warn here with '#nullable disable warnings'
    public partial void M1(string? s);
    public partial void M1(string s) { }

    // implementation accepting "more" than definition is safe, but we warn here with '#nullable disable warnings'
    public partial void M2(string s);
    public partial void M2(string? s) { } // warning CS8826: Partial method declarations 'void C.M2(string s)' and 'void C.M2(string? s)' have signature differences.
}

Discussed a bit offline. At this point, permitting "safe" variance without warnings seems like the right thing for nullability and scoped. I feel like erroring on object/dynamic differences is right here and ignoring tuple name differences is right. It feels a tiny bit arbitrary sometimes...but open to feedback on some of these decisions.

test a valid case with large numbers of interceptors. (EndToEndTests?)

Are we testing a large number of interceptors (and intercepted calls), to ensure there are no obvious perf issues with resolving intercepted calls?

Not yet. I should have noted that some of these were moved to the test plan, but not checked off yet.

From offline discussion, maybe this should be moved into CompileMethodBodies and maybe CheckDuplicateFilePaths as well.
Then the ERR_ModuleEmitFailure reported in TryGetInterceptor becomes unnecessary.
That's okay as a PROTOTYPE

Also consider adding tests for duplicate interceptions and duplicate file paths in a compilation for ref-only assembly (showing whether or not we ran those checks).

This comment also seems relevant.

#67786 (comment)

Basically, the search is for a consistent place to report duplicates at the end of the declaration phase. This place would be appropriate for both duplicate file-local types and for interceptors.