Teemu brought up the current event declaration behavior today, and even pointed to a bug report about it.
I'm going to take the opposite stance. putting the onclick="whatever" attribute on the tag is the best solution to a complicated problem. Now, if the problem were limited to the points that Teemu addresses, then yes, it looks like it should changable based on the current dev model. However, the thing that makes this problem more complicated is that not every control is at the top level of your page. Asp.net uses a hierarchal declaration system with containers and child controls. One by-product of this system is that not all design-time-selectable controls on your page have references at the page level, or even refer to a single instance of a control ( in the case of a databound template declaration ).
So, if you drag a button onto your form, and double click it to add a hook to the Click event, there are 2 or 3 basic choices ( depending on language ( VB has the Handles thing going on ))... add the glue to the tag, or add it in some initialization code block. Some want to use the code block because they don't like their UI declration to know the name of the handler function of the event.
However, the hole there is that if you now move that button from the top level of the page's heirarchy, into a INamingContainer like a Repeater's ItemTemplate, then the instance referenced in the initialization-block doesn't exist. ( VB's Handles doodad breaks here too )
So how should the designer attach to events in child controls if there is no top level instance to code against, nor any guarentee that the child control will exist at any given initialization time ( or be instantiated at all during that request for that matter )? To me, it seems it can't ensure correctness with any way but declarative. Which follows to the next point... Should it really use two completely different hookup mechanisms for top-level and child controls? I assert that it shouldn't as that would lead to some nitemare maintainability problems. ( "I know that it's hooked up somewhere, where did that code block go now?" ) Therefore... the tag declaration is the correct place for the designer to hook up event handlers.
1) No OGG support. Come on Microsoft, you can do it. I know you can. You were even willing to ( apparently ) pony up the money to include high bitrate mp3 encoding. You can't hire a contract/temp developer for like a month to add support for completely free and open codecs? This is really a non-starter for me. If your player doesn't support 1/3 of my music, i'm not going to be using it.
2) The "web video" problem. Ok, this one is a bit more complicated. I'm the kinda guy that plays music 24x7. Regardless of what else i'm doing, I want my music playing. So, ok, here's the scenario... I'm surfing... I click a video link... Now, the old behavior was horrible. It used to just completely blow out your current playlist and play the video. For v10, they "solved" this problem in a half-assed way. Now, your current playlist is saved, the music is paused, and the video plays. Sure, this means you can go back to your music after the video is done, but that's not the behavior I want. What I want is for the music to CONTINUE PLAYING while the video plays. And more than just complain about it, I'll offer a solution too. It seems to me that the right way to solve this is to allow the user to "pin" an instance of wmp. A pinned instance won't be reused by other applications which open media. So I could open one instance of wmp, get my music going, and pin that instance. Then if I want to view a video clip those will be opened in a new window. Unfortunately, since something like v7 of wmp, multiple instances of wmp has not been possible. So while this is the right answer, I doubt it will ever happen.
So anyway, until BOTH of these issues are fixed, it's winamp for me.