Considering the way the XNA framework is structured, what is the 'cleanest' way to utilize it?

I am just pondering about two things:

1) The screens in the application/game
Currently I do have a couple of classes for organizing screens/scenes: SceneManager, Scene, SceneObject. The SceneManager holds a collection of scenes and is inherited from DrawableGameComponent. Scene is a base class for a scene and each scene inherits from it. SceneObject is a base class for an object in the scene and is inherited from DrawableGameComponent extending it by a few properties. The SceneManager keeps track of the currently active Scene and chains through the calls from the Game like Update and Draw. This structure makes sense to me, but for some reason I have the feeling that I unneccessarily write my own render loop in the Scene class.
The question is, if this would be a cleaner approach (cleaner in the way, that "the way the framework was intended to be used"): Each SceneObject gets a name of the scene it belongs to and is added directly to the GameComponents collection. The SceneManager is just a GameComponent (non drawable) and is updated first, on a scene switch it disables and turns all GameComponents belonging to the current scene invisible and turns the one for the current scene on.
It also truely depends on how the ComponentCollection of the Game is implemented, which I do not know. My current Scene component collection is a wrapper of actually 7 lists: all GameComponents, updateable GameComponents, disabled updateable GameComponents, enabled updateable GameComponents, drawable GameComponents, ... So that the Scene when it updates request just an enumerator for the enabled updateable GameComponents, for drawable only the list of enabled drawable GameComponents and so forth. When a GameComponent is enabled/disabled it is inserted or taken out of a list. This ensures that during the render and update loop of my scene only affected components are touched. Does ComponentCollection of the Game work similar? Because otherwise, assuming I have 10 scenes with 100 objects each, each draw and update call would touch 900 unneccary objects, which might affect the performance.
If the ComponentCollection is not working similar, would it be an alterantive if the SceneManager keeps a list of all SceneObjects and removes and adds them to the ComponentCollection of the Game if a scene switch occurs?

2) The render loop and z-sorting.
Well, I do have my own way adding mesh parts to a list first and then sorting them by transparency, z-order and effect with a fuzzy factor to minimize artefacts and effect switches, but for the first shot and simple scenes I stick with the list of DrawableGameComponents in my Scene class as described above. Assuming I would switch my scene organization like described above, I would rely on the DrawOrder of the GameComponents. I could go ahead and have each GameComponent recalculate its DrawOrder value based on the distance to the camera, the effect and so forth. Then DrawOrder values could be in a predefined range and with an accuracy distribution maybe like the standard the z-buffer as we know it (closed most accurate). Was that the intended way to use the DrawOrder property or will the ComponentCollection perform badly if it has to handle all the DrawOrderChanged events (if it does)?
Again, I think this comes down to the ComponentCollection of the Game. Does it resort the whole list if the DrawOrder of a single item changes or does it just find the new position of the item in the list? Assuming it keeps the DrawableGameComponents in a sorted list by DrawOrder, recalculating the DrawOrder of n objects would by just O(n*log n) if only the item that changed is repositioned, by O(n*n*log n) if the list is always resorted completely - at least if I remember correctly ;).

It is nothing important, everything I have works as it is, but once in a while I look back and some things in the architecture or code appear to me somehow not right or unbeautiful ;)

Alex