Spec: https://github.com/dotnet/csharplang/blob/main/proposals/extension-indexers.md
Championed issue: dotnet/csharplang#9856

Compiler

• LangVer
• round-tripping
• IndexerNameAttribute and DefaultMemberAttribute
• ref analysis
• Nullability analysis
• CREF binding
• disallow dynamic arguments
• test with unsafe evolution (extension indexers marked as RequiresUnsafe)

Pending

• Interpolation handlers
• StackOptimizer assertion
• NullableWalker.DebugVerifier assertion
• Check that EnC is blocked

Undone

• Public APIs (GetMemberGroup)
• Diagnostic quality
• Ping the docs/learn team
• indexers tracked follow-ups: Extensions: indexer follow-ups #78829
• Spec: countable properties, update speclet for "Range" feature to be explicit about extensions
• Spec: setters with params (see Nullability_Params_10)

Productivity

• FAR (should include disambiguation callers)
• AddParameter, ChangeSignature
• Rename (blocked on disambiguation call)
• RemoveUnusedValueAssignment
• RemoveUnusedMembers

Features for discussion

Aside from extension indexers, there'll be some refinements to baseline extension feature to consider (from C# 14 cut list and other ideas):

1. consider tracking state for extension properties: Extensions: Confirm whether we should track nullable state for extension properties #81913
2. nameof to extension property: `nameof` doesn't work with extension properties csharplang#9655 and CS0103 Triggers for nameof-expression inside extension property #81496
3. support for partial (Generated code (GeneratedRegex, LoggerMessage) does not work inside new extension blocks runtime#121593 (comment), Source generator does not function inside an extension block #81165 (comment))
4. readonly members (Extensions: disallow readonly members csharplang#9774 (comment))
5. const members
6. (non-extension feature): inference from constraints
7. access on generic type parameter: Generic static extension member errs when used on a type parameter csharplang#9651
8. consider adjusting receiver requirements for extension members: Extensions: consider adjusting receiver requirements for extension members #79451
9. disambiguation between extension method and property, or betterness before determining member kind: Extensions: Extension method prevents extension property of the same name from being accessed csharplang#9653
   I'd probably not pursue/champion these:
10. two phase or partial type inference
11. CREF to extension block
12. considering some top-level syntax (potentially to alleviate factory scenarios)
13. empty blocks