MSDN describes HttpContext.Items as being used to:
organize and share data between an IHttpModule interface and an IHttpHandler interface during an HTTP request.
MSDN doesn't make any recommendations about storing references to Page Controls in this collection. I know the Items collection outlives the Page lifecycle because it is associated with the request.
The reason I'm asking about the potential to store Control references in the Items collection is because we're considering making some page controls that sport a certain (known) interface to register themselves with the page upon Load. This is because the position of the controls in the page may change as they are configured by the end user through a Content Management System - this is how the page is assembled. We want to stay away from recursing the page control hierarchy and instead make the Controls offer themselves up directly through registration.
The best case is that somebody shoots down this idea for a good reason because they've thought of an issue that we haven't or have a better idea to achieve the same thing.
An ASP.NET Page is also an HTTP Handler through IHttpHandler interface implementation and therefore is a valid candidate to use with the HttpContext.Items collection by definition in the MSDN document.
Because Page Controls are effectively in a handler there seems no apparent risk to reference page controls from the Items collection.
My main concern was lifetime of control objects in context of the Page versus longer lifetime of the request/context the collection relates to. However Controls will still be disposed properly through IDisposable when the page is complete and the garbage collector will still clean up Controls when they are finally released from the Items collection which shouldn't be long after the page handler expires.