This is why I preferred how things were done in C# 1.0: you could call methods with optional arguments, but not define them yourself (after all, you're far more likely to consume COM in .NET rather than write COM servers). I don't buy the arguments they
made for introducing it in C# 4.0. If people really needed it then they should have used attributes and so kept the core language clean.
Is the language really "polluted" by optional parameters? I don't see it. Besides, this was requested by many people. The endless overloads with one more parameters just went away in a flash.
Say C# were to be refactored to something like D# then optional parameters would not be on my list of things to dispense of.
It would be to streamline the language for immutability, genericity, non-nullness, numerics and in-memory query performance (read: LINQ to Objects).
Wouldn't it be cool if nullness was dealt with by the maybe monad and we could just chain together nullable expressions without worrying about run-time blowups; if perhaps exceptions by the error monad - with some syntactic support; if = meant equality and
:= (or <-) meant assignment; if "assigning" to a structure didn't change it but constructed a functional variation of the old one, using techniques from persistent data structures (or the state monad?)
Then there's the tension between interfaces, abstract classes, partial classes and extensions; many ways to skin a cat, none entirely general or generic.
I'm getting close to biting the F# bullet, except there's no Visual F# Express, and I'd most likely only be using this at home for hobby projects, for the next couple of years.