Hi Don,
In my opinion, how to manager your LifetimeManagers and the corresponding registered instances will depend of the requirements of your scenario and your personal preferences. If in your scenario you are providing a single UnityHttpContextPerRequestLifetimeManager for all the instances of that type, it might make sense to only dispose the instances associated to a request instead of the LifetimeManager itself.
Based on my understanding, in MileageStats's scenario, an instance of UnityHttpContextPerRequestLifetimeManager is created for each registration and for each request. Therefore, it seems that in each request MileageStats have a UnityHttpContextPerRequestLifetimeManager per instance and each manager is only in "charge" of its associated instance. In such scenario, when an instance is removed from the container, it makes sense to dispose the manager too, as it's not in "charge" of any other instance. Then, at the end of a request, MileageStats disposes the corresponding UnityHttpContextPerRequestLifetimeManagers for that request, which also removes the instance from the container in its Dispose method.
This is the approach followed in MileageStats's scenario. If as you mentioned your scenario is different and your LifetimeManagers will be need as long as the container's lifetime, it makes sense to remove only the instances and not the LifetimeManagers. Then again, this will depend of the requirements of your scenario and your personal preferences.
On a side note, as it's name implies, I believe that the UnityHttpContextPerRequestLifetimeManager was designed to be created and disposed in each request. I'm unaware if a single instance of this LifetimeManager can be used for several requests and it might be possible that you will need to modify it with your custom logic to be used in such scenario.
Thanks,
Damian Cherubini
http://blogs.southworks.net/dcherubini