Den Delimarsky

@seanmonstar any chance you could take a look at this PR? This is impacting some downstream projects that are breaking because of a library-caused panic.

They are not dupes. While they have the same signature, their type parameters are different: ``` S ``` @TianqiZhang @joelmartinez

@joelmartinez we use DocIDs to detect things, instead of the C#/IL signatures. Since we have two identical DocIDs, and we have the same DocIDs in the `FrameworksIndex`. I think it...

@joelmartinez sounds good - second proposal is reasonable.

For the above, these are the links for generated ECMAXML that are inconsistent: - https://github.com/dotnet/dotnet-api-docs/blob/master/xml/System.Activities.Presentation.Model/ModelItemDictionary.xml#L681 - https://github.com/dotnet/dotnet-api-docs/blob/master/xml/System.Collections.Concurrent/ConcurrentDictionary%602.xml#L1156 - https://github.com/dotnet/dotnet-api-docs/blob/master/xml/Microsoft.VisualBasic/Collection.xml#L790 cc: @mairaw @joelmartinez

Looks like for (3) you already have a path to resolution @joelmartinez! Thank you for working on this.

Seems like a non-repro in my case. @TianqiZhang please confirm once I send you the updated instructions.

@joelmartinez do we have any sort of differentiation between the parameter types that are being fetched inside members? I am guessing that is not the case because `mdoc` does pure...

@TianqiZhang can give examples of members that cause this issue.

@TianqiZhang @mairaw @BillWagner - does this have anything to do with the content that we imported into ECMAXML instead of re-generating it? Given that `mdoc` is not likely the source...