1. A big cause of grief going around right now is the impact on real enterprise developers of the decision to have web projects not have project files. Yes, this was a decision made in the name of simplicity -- and for 99% of the web developers out there that ASP.NET targets it probably was a very good decision. But once again the problem is that this simplicity is being forced on the rest of us, and many of us enterprise developers really need many of the capabilities the project file gave us. Should MS have known better -- most definitely yes -- I for one tried to warn them about this very issue at the first Whidbey preview in October of 2002, and I think I was probably the one attendee that best represented real enterprise developers as opposed to authors and trainers.
2. Another "problem" that was introduced with ASP.NET v1 and is now getting worse is that MS gives us "rich" web controls with properties like backcolor, font, and width. Unfortunately, there are no such html attributes -- everyone of these properties is instead actually part of the html element's style. Yes I realize this simplifies things greatly for newbies, but all its done is "teach" more people that CSs isn't important -- and its made real CSS stylesheets much more troublesome to use in ASP.NET. Think I'm off my rocker? Did you know that the Calendar's Title CssClass did not work at all in v1 since no one ever bothered to test stylesheets adequately? Want another example? Did you know that WebPartZones, yes that new wonderful portal technology in ASP.NET v2, will not work with the CssClass properties -- and according to MS that's "by design" and "postponed"? I was really hoping to use WebParts, but all I had to do was try to use it with CSS stylesheets (don't most portals work that way) and I realize they are pretty much worthless -- not to mention take a look at the ugly html they produce. And what's the work-around for this you ask -- Themes and Skins. I know that Themes and Skins are one of the cool new features of ASP.NET v2, but have you ever stopped to think that they wouldn't be needed if we just used CSS stylesheets!
Now to their credit, they have fixed a lot of these issues in the ASP.NET Forums over the years -- the delete post link now uses the actual key for instance -- but many of these very real bugs persist. The standard method of not using the key is also not very performant, since even if you forget the case of data changing you still have to re-query the database just to do something (and then query it again to get the final set of data to display after the change) -- unless of course you put all the data in viewstate. Note that I do not want to imply that postbacks, viewstate, controls, or any other feature is inherently wrong -- I only want to point out that the simplification has went too far and can actually affect data integrity and/or performance if you use a lot of the defaults. For me this means that I never use the datagrid for more than the simplest of pages or prototypes (if even then) -- and that's really not even a burden once you've used the repeater a few times, or written your own "grid". But the problem persists (and most people don't even realize it) -- and just as bad there are now thousands of articles out there to help you figure out how to get around all the various short-comings of these simple controls. Why? Because this simplicity is great when it works, but unfortunately its teaching many web developers to never do anything else -- I can't even begin to count the number of "huhs" I get when I respond to questions about the datagrid that I don't know because I don't use it.
OK, end of post -- I hope I didn't lose everyone -- or make you think I've lost it. I really do love ASP.NET, and I do appreciate the folks on the MS ASP.NET team, and I do understand the needs for some of this simplicity so that they can reach out to a much wider pool of web developers -- I do not want their job. I just think that sometimes what is simple in the short-term or small cases ends up being anything but simple in the long-term or bigger cases -- so there needs to be a better balance in some cases to not make things too easy just because someone wants it that way. I encounter the same types of things even with my ORMapper -- why can't you just do this thing that would make my code go from 3 lines to 1 line, even though it will make other situations far worse -- that's not simplicity to me.