Difference between IEnumerable and IEnumerable<T>?

Basically the nongeneric interfaces came first, in .NET 1.0 and 1.1. Then when .NET 2.0 came out, the generic equivalents came out. Life would have been a lot simpler if generics had made it into .NET 1.0 :)

In terms of implementing "only" IEnumerable<T> instead of both - you basically have to implement both, and you have to use explicit interface implementation too, given that both define a parameterless GetEnumerator method. As IEnumerator<T> extends IEnumerator too, it's normally something like this:

public IEnumerator<T> GetEnumerator()
{
    // Return real iterator
}

// Explicit implementation of nongeneric interface
IEnumerator IEnumerable.GetEnumerator()
{
    // Delegate to the generic implementation
    return GetEnumerator();
}

On the other hand, with the iterator blocks introduced in C# 2 (with yield return etc) you rarely need to implement these things entirely by hand, fortunately. You may need to write something like the above, and then use yield return in the GetEnumerator method.

Note that IList<T> does not extend IList, and ICollection<T> does not extend ICollection. That's because it's less type-safe to do so... whereas any generic iterator can be seen as a nongeneric iterator due to the (potentially boxing) conversion of any value to object, IList and ICollection allow values to be added to the collection; and it doesn't make sense to add (say) a string to an IList<int>.

EDIT: The reason why we need IEnumerable<T> is so that we can iterate in a type-safe way, and propagate that information around. If I return an IEnumerable<string> to you, you know that you can safely assume everything returned from it will be a string reference or null. With IEnumerable, we had to effectively cast (often implicitly in a foreach statement) each element that was returned from the sequence, because the Current property of IEnumerator is just of type object. As for why we still need IEnumerable - because old interfaces never go away, basically. There's too much existing code using it.

It would have been possible for IEnumerable<T> not to extend IEnumerable, but then any code wanting to make use of an IEnumerable<T> couldn't call into a method accepting IEnumerable - and there were a lot of methods like that from .NET 1.1 and 1.0.

One returns an object of type Object, the other returns an object of type T.

As to why you see classes defining both, enough though IEnumerable< T > implements IEnumerable, its not needed but is is nice in a self documenting to list the sub interfaces at times. Consider

interface IA { }
interface IB : IA { }

class A : IB {} // legal, IB implements IA

class B : IA, IB {} // also legal, possible more clear on intent