"But I don't want to have to worry about sprite depths..."

Well, you don't have to really. Or maybe you're already dealing with depth and you don't realize it.

To recap: There are two ways of controlling sprite "depth". The first is to use the SpriteBatch.Draw methods that allow a layerDepth parameter. The second is just to draw your sprites at the same depth, but from back to front.

The layerDepth approach is nice when you have lots of sprites at different depths, or when they're changing depths regularly. You give each sprite a depth and then forget about it. This allows you to draw your objects ordered by type (first the map, then the player, then the objects, ...) as opposed to by how far they are into the screen.

The simpler approach of drawing from back to front is seen when you draw your background first, then your objects and then finish up with your overlay and UI elements. Basically, you've hardcoded your back-to-front sort order in your code. Not very flexible perhaps, but perfectly appropriate for a large number of games. And you don't have to worry about depth at all - beyond the coarse background/objects/overlay distinction.

XSpriteManager supports both approaches. If you give it a depth, the right thing will happen - and the sprites will be kept in sorted order so that they render quickly. But if you don't want to set the depth, you can just add sprites and they will be rendered in the order that they were created. By default, XSprites are drawn at depth=0.0 (which is closest to the screen).

The motivation for all this is the game that I'm working on (big surprise there, eh?). It's a basic tile-based isometric RPG which had a definite need for a class to manage all the sprites. To handle the map tiles, I wanted to put each row at a different depth and then place the player (and NPCs) at depths between the rows.

I'll try to talk more about this game once I get a few more basic classes finished up.