If the class does not implement IDisposable , the code that uses the class is likely to create and leave instances without checking them to make sure that they implement IDisposable . Even if a later version of the class implements IDisposable , this change will not magically produce code that never checks IDisposable to magically start calling IDisposable.Dispose ; client code that explicitly checks for IDisposable and tries to call Dispose if possible (for example, code generated by the compiler associated with foreach blocks) will start calling IDisposable.Dispose once, which will be possible, but most of the code does not bother.
Note that not all code that uses an object will have to worry about its implementation of IDisposable . The only time that something should call IDisposable on an object is the last thing you need to contain a “useful” link to it. If the code gives the method a reference to the object, and the method will not do anything with the object after it is returned, the caller can easily find out when the method is executed on the object, and thus the caller will be as capable of calling Dispose as the method. Therefore, there would be no reason to call the Dispose method. On the other hand, if the code calls the implementation of the IEnumerable<T>.GetEnumerator , and this method needs the services of the object that will need to be cleaned after the enumeration is completed, the only way that the object that implemented GetEnumerator could be implemented when the services are not longer takes if the code that called GetEnumerator calls Dispose on the returned enumerator if it is no longer needed.
By the way, the need to call the IDisposable.Dispose object returned by the factory method, like GetEnumerator , does not necessarily depend on the type of the returned method of the factory method. If you call a non-generic IEnumerable.GetEnumerator() object, then semantic correctness requires that one checks whether the instance of the returned object implements IDisposable (it can do this even if the declared type IEnumerable.GetEnumerator() does not work) and calls Dispose on this if so. From this point of view, if a later version of the abstract base class implements IDisposable , when earlier versions did not, it really cannot be a change. If the code that the factory called methods returning the abstract class were required to call Disposed on the returned elements whenever possible, using the IDisposable base class would not add any new responsibilities to the client code - it would simply make it easier for the client code actually take care of those responsibilities that he should have had in any case (checking whether the instance of the IDisposable object implements is slower and more cumbersome than unconditionally calls IDisposable.Dispose in the class that implements this as do-nothing method).