Regarding (1): You should never hold unmanaged resources in static variables. It makes the lifetime management more or less impossible to get right.

Regarding (2): This is why I said what I said for (1). There is no reliable way to make this work. If you release the resources in an instance's Dispose() method, any other instance is broken: the resource is gone, but the static member variables are still in scope. If you don't release the resources in some instance method, it's broken because you never release the resources.

If you really want one copy of the unmanaged resources, wrap them in a type that implements the Singleton Pattern.

So, don't store unmanaged resources in static variables. Ever. It won't work.

I'm still not sure it's a common pattern, but there might be some instances where this might work.  It's a small resource leak, but there are instances where you don't really care.

Suppose you create some type that needs to hold a resource that implements IDisposable, and that type will have a lifetime that mirrors your application's lifetime. Well, then a static member variable means that you only create one copy of that resource in your application. However, you'll never release that resource. However, it will get cleaned up when your app exits. So, no real problem. It's a little fragile, because you will have quite a bit of work to do if your application changes later and your resource's lifetime no longer matches the application's lifetime.