This doesn't look accurate. In this case, "they do include the arity suffix in the metadata names", the suffixes will be preserved by C# because they are in metadata names and C# doesn't remove them from metadata names. #Closed

This paragraph is about docIDs from C# source or metadata. It relates to the first bullet. I'll make that more explicit.
The illustration for metadata from some other tool (ie. second bullet) is below.

Here as well. #Closed

I think there is another doc id that includes type parameters, which drops the arity suffix, and that also causes slightly different issues. Consider including examples of those too. #Pending

I think there is no issue with ExtensionMarkerName. A conventional name for it wouldn't include any arity suffix, because from language perspective marker type inherits all type parameters from the enclosing grouping type, therefore itself not generic from C# or VB point of view.

class C1<T, U>
{
    class C2
    {}
    class C3<S>
    {}
}

Checkout metadata name for C2:

.class private auto ansi beforefieldinit C1`2<T, U>
    extends [mscorlib]System.Object
{
    // Nested Types
    .class nested private auto ansi beforefieldinit C2<T, U>
        extends [mscorlib]System.Object
    {
    } // end of class C2

    .class nested private auto ansi beforefieldinit C3`1<T, U, S>
        extends [mscorlib]System.Object
    {
    } // end of class C3`1
} // end of class C1`2

#Closed

Is there a type parameter? #Closed

Is there a type parameter? And, as I mentioned above, there should be no arity suffix here #Closed

Is there a type parameter? #Closed

Is there a type parameter? #Closed

Why wouldn't they match? The types aren't generic, therefore suffixes wouldn't be added or removed by compilers. Perhaps there is a mistake in the IL and types should be generic? Suffix doesn't make types generic. #Closed

IL got adjusted and the thread was resolved, but I am still confused by the names below. What tool/component would produce the names below? Why the arity suffix wouldn't be there? It will be part of ExtensionGroupingName for C# and VB would include the suffix as well. Probably in this scenario there could be a problem with a doc id that includes type parameters instead?

Effectively we are proposing that ExtensionGroupingName should reflect name of the emitted grouping type from language perspective, not its emitted name. Emitted name should follow naming convention used by C# for types declared in source. I think this should be clearly stated. #Closed

Taking my previous comments into account. ExtensionMarkerName reflects name of the emitted marker type from language perspective and its emitted name at the same time. Both names are equivalent. No need to change here. #Closed

and marker types

Consider dropping marker types from this sentence since no change is proposed for them. #Closed

as needed

The "as needed" part is confusing because, in my opinion, in some scenarios compiler adds suffix when it is not needed. However, I think we are not proposing changing that part. Perhaps "in a way consistent to the current handling of regular generic types" would reflect what is proposed more accurately. #Closed

and marker

Consider dropping marker types, they are not affected #Closed

and ExtensionMarkerName

Consider dropping marker types, they are not affected #Closed

and marker types

Consider dropping marker types, they are not affected #Closed

The grouping and marker names are the metadata names.

Consider dropping this sentence entirely. #Closed

Current compiler's behavior is a proof of that because right now it has to load grouping types without suffix. #ByDesign

What does it mean that metadata name would be mangled from ExtensionGroupingName? As I understand from the examples, the metadata name would be just ExtensionGroupingName plus the arity suffix appended. #Pending

Yes, mangling means adding an arity suffix

produce

Typo? "produced" #Closed

to include arity suffix to the ExtensionGroupingName

It feels like this contradicts the next sentence. This now reads as ExtensionGroupingName going to match metadata name. Then there is this sentence below: "Then we'd produce the docIDs as described above, by appending an arity suffix to ExtensionGroupingName ..."
Why would we need to add suffix if we already added it?

I think the previous wording of this sentence was fine, we just needed to not mention marker type. For example: "We're proposing to update the metadata design to include arity suffix in the metadata names for grouping types." #Closed

Type parameter? #Pending

Consider doing a find/replace for this int and in this doc and fixing up all cases.

Done. Thanks