Many of the most time-consuming, polarizing debates in software development are the constant back-and-forths over trivial code style: Tabs or spaces, 2 or 3 spaces, curly bracket at the end of line or beginning of the next, and so on. While C# improves things a bit in that it, by default, does some formatting (such as curly bracket placement), they could have taken it a step further - the source should always be stored in a clear, defined and standardized XML storage format. e.g.

<namespace name="Microsoft.LameExample">
  <class visibility="public" name="MyClass">
    <method visibility="public" type="instance" name="Run">
      <call>
        <method>System.Windows.Forms.MessageBox.Show</method>
        <parameter>Hello!</parmaeter>
      </call>
    </method>
  </class>
</namespace>

I'm hardly the first to advocate this (and of course it's what most of us thought about when we first started getting a handle on XML many moons ago - how can we apply this to software development), and while I thought I was original thinking up the term CodeML, there are actually already plenty of references to it out there. It's a pretty obvious idea.

With such a structure not only would language parsing be much easier for third-parties to interact with, but most importantly it would allow each user's environment to stylistically render the code however they want. Source control systems could (should) be schema aware, intelligently doing change management, and we wouldn't have massive change sets caused by someone running a reformatter to update to the standard of the day, switching from tabs to 3 spaces (python's use of whitespace to meaningfully indicate blocks/scope is absolutely brilliant, as an aside), or updating the curly bracket standard. What a complete waste of time and effort, and what a ridiculous distraction from actually solving problems.

Of course we still have the issue of case sensitivity - I'm still on the fence about this. I love C & C++, and I've always hung onto their case sensitivity out of habit ("real programmers pay attention to case"), yet it's possibly just another needless distraction. There really are very few instances where you want overlapped names, differing only by case.

It was, I think, an ugly decision to incorporate case sensitivity into .NET.

If there were no case sensitivity issues then this too could be an environmental option (e.g. all identifiers are stored in upper or lower case in the XML file, but then rendered according to user preferences - consts all upper case, parameters camel cased, public methods pascal cased, and so on. No need to "correct" such a menial thing in other people's code. The IDE knows what each of these things are and what their visibility is, so there should be no need to crystalize such a pseudo-Hungarian notation in our code).

This is of course just off-the-cuff thoughts after hearing yet another reformatting debate, so temper your criticism accordingly. I'm also pragmatic enough to realize that making a standardized schema for something with as many edge conditions and exceptional circumstances as source code isn't quite as easy as it sounds.