Private nested static class - Good or bad practice?

Both approaches are entirely valid.

I wish developers would use private nested classes more often. In conjunction with c#'s partial keyword, it makes writing very complex classes much more maintainable. Imagine needing to build a class that has the complexity of a small application - much easier when you actually can build an entire private application, with classes that are totally internal to your complex outer class!

One very common case I've seen is enumerables - these can be quite complex, especially when you start building custom iterators that can be chained, like LINQ. Hiding the complexity inside the individual classes is the very definition of encapsulation.

There's nothing wrong at all with this, and why should there be?

The scope is limited, so that only instances of the outer class have access to it, and it's a great place to put constants and other common functionality that is private to the functionality of the outer class, without having to instantiate it all the time.

I don't see this as anything but good practice.

If the class is used in a multi-threaded application, you may need to control access to the static state via locking. That's a problem with static state whether privately nested or not.