Why are extension methods only allowed in non-nested, non-generic static class?
As Pratik points out, the question we face is not “why are extension methods not allowed in nested or generic classes?” The question we face as language designers is “why should extension methods be allowed in nested or generic classes?”
Unless the feature is justified by some real-world user need, we’re not going to take on the considerable costs of designing, implementing, testing, documenting and maintaining the feature.
Basically, extension methods were designed to make LINQ work. Anything that didn’t contribute to making LINQ work was cut. LINQ only needs extension methods in static, non-generic, non-nested classes to work, so that’s what we designed and implemented.
If you have a scenario where extension methods would be useful in non-static, generic, or nested classes then I’m happy to take a look at the scenario. The more real-world scenarios we get, the more likely it is that we’ll make a feature in some hypothetical future language that benefits those scenarios.
Is it useless to consider extension methods in nested, generic static class?
No, it is a great idea to consider it. We would be remiss in our duties if we did not consider it. We considered it carefully for a long time and decided that on the basis of that consideration, the costs of doing the feature were not justified by the benefits accrued.