For several years now I've disliked how ASP.NET provides a page lifecycle that is unrelated to the "business", or let's say, "functional" side of the application domain, and is pretty inflexible.  The ASP.NET page lifecycle is strictly in the technical domain, with the possible exception of the Validate() method.  This lifecycle is pretty low-level.
 
However, typical applications have a higher-level set of actions, many of which are performed by the user:  things like "Save", "Save and Add New", "Authorize", "Create From Template", "Cancel", "Delete", "Select", etc.  The natural thing to do is create an API within the application to support these activities.  If you're lucky, you can make this a cross-cutting API that works generically for each feature on all the applicable pages.
 
The problem is that there's an impedance mismatch between the ASP.NET lifecycle API and the (for lack of a better word) "business domain" API.  It can be hard to determine where in the ASP.NET model to put certain code.  What's worse, it may need to be in a different place in one page than in another; for example, before loading some data in Page_Load(), you may need to know whether you will be handling some event from a control, or you may need to handle the event first.
 
I understand that in .NET 2.0 it's actually possible to override the code that provides the ASP.NET page lifecycle, but this seems like a drastic solution and one that leads to a hard-to-maintain application.  I've also read about some efforts towards aspect-orientation that might provide some relief.
 
One solution I thought of is to have some sort of state machine that would allow specification of the lifecycle in a database or other structure, and then fire things off dynamically.  This would be embedded in Page_Load() or some other standard place, and would give developers full control over how the page runs, with the benefit of being able to use a standard, business-oriented lifecycle API.
 
Food for thought :-)