I was testing the Episerver prerelease 11.1.0 with Alloy demo site and noticed that sometimes the container pages were displayed in the top navigation (they shouldn't be).
I debugged the code and believe I found the reason why this might happen. To me it looks like the injected property template resolver in FilterTemplate class can get the wrong implementation (not the same that the Alloy CustomizedRenderingInitialization has hooked event handler to). So in short I think the EPiServer.Web.Internal.TemplateResolverImplementation and EPiServer.Web.Internal.DefaultTemplateResolver registration are competing in the registration order randomly and that is why the FilterTemplate might get the "wrong" implementation.
Debug logging when working incorrectly:
CustomizedRenderingInitialization, registering for templateresolver (type: EPiServer.Web.Internal.TemplateResolverImplementation, hashcode: 40517777).
FilterForDisplay, templateFilter templateresolver type: EPiServer.Web.Internal.DefaultTemplateResolver, hashcode: 23615301
// eventhandler in [Alloy].Business.Rendering.TemplateCoordinator.OnTemplateResolved
Set SelectedTemplate = null, templateresolver hashcode: 40517777, type: EPiServer.Web.Internal.TemplateResolverImplementation
So as you can see from above log entries the menu creation used FilterForDisplay method used TemplateFilter is using another implementation for the templateresolver => no events for the registered handler that would set the template to null for container pages.
Debug logging when working correctly (the container pages are not shown in the menu):
CustomizedRenderingInitialization, registering for templateresolver (type: EPiServer.Web.Internal.TemplateResolverImplementation, hashcode: 62773796).
FilterForDisplay, templateFilter templateresolver type: EPiServer.Web.Internal.TemplateResolverImplementation, hashcode: 62773796
// event handler in [Alloy].Business.Rendering.TemplateCoordinator.OnTemplateResolved
Set SelectedTemplate = null, templateresolver hashcode: 62773796, type: EPiServer.Web.Internal.TemplateResolverImplementation
Here you can see that the TemplateFilter is using the same implementation and instance as the registered handler and the pagecontainer templates are correctly set to null and not visible in the menu.
Looking at the code I can see that the DefaultTemplateResolver has no module dependency when it is registered just with the ServiceConfiguration-attribute and the TemplateResolverImplemenation is registered using dependency to CmsCoreInitialization (EPiServer.Initialization.Internal.TemplateInitialization).
Might be that this is already fixed in mondays bits :)
Thanks for helping us testing out the pre-release packages. The issue you are refering to have been fixed in later builds, and you correctly identified the root cause.
ITemplateResolver was though correctly registered in the container both when it was working and when it was not working, problem was that there was a missing registration of ServiceAccessor<ITemplateResolver> and for whatever weird reason StructureMap ends up with different answers every time.