For most people this will not be an issue at all.  Most people don’t care about the control hierarchy of the Page, but to make highly-customized pages, you’ll get to know this very intimately.  In v1.1, every control on the page was in the Page’s Controls collection, so if you needed to get a reference to a user control, for instance, you could declare the user control as a member variable or you could find it at runtime:

(MyUserControl)Page.FindControl(”ucMyUserControl”);

I’ve seen this method in plenty of code samples around the .Net, and I’ve even used it myself.

In version 2.0 (as it stands in Beta 1), if you user a Master Page along with your Page, this will not work.  Let me tell you why.  When you apply a master page, that master page has a ContentPlaceHolder control, and your page has only an <asp:Content/> control.  This Content control get stripped and discarded and never makes it to the final Page control structure.  The contents of the Content control are merged into the ContentPlaceHolder.  The result is that the page ends up with only 1 control in its Controls collection:  a ContentPlaceHolder from the master page.  That leaves you to modify the above code to :

(MyUserControl)Page.Controls[0].FindControl(”ucMyUserControl”);

or you could otherwise find the ContentPlaceHolder first and then do the FindControl(). 

I don’t know the reasoning for this change.  I would reason that the <asp:Content/> controls should merely be added to the controls collection of the master’s ContentPlaceHolder.  This would result in less rearranging of the  Page’s control hierarchy. 

Overall, the master page feature is very nice.  The IDE provides great RAD features for this, but my team develops an enterprise application that HAS to be maintainable, so RAD goes out the window.  The master page is set on the PreInit method in our base page, and by the Load method, everything is where it should be ready to be used.