Extension methods can operate on a null instances (http://stackoverflow.com/questions/847209/in-c-what-happens-when-you-call-an-extension-method-on-a-null-object).

Rather than requiring the user always validate that they have a non-null enumerable before applying an operation, it is nice when the extension method supports null instances.

An example of where this is not the case in MoreLinq is ForEach: https://code.google.com/p/morelinq/source/browse/MoreLinq/ForEach.cs

Notice that ForEach throws an ArgumentNullException if source is null. However, I believe that it would be entirely reasonable to simple return early instead. This would allow the user to call ForEach on the enumerable without having to run it through something like (myEnumerable ?? Enumerable.Empty<MyType>()).

The ForEach is just an example, it would be nice if the entire MoreLinq library followed this pattern and treated null enumerations the same as empty enumerations. e.g., Concat would just return an enumerable with one item if the source was null, the same as you would get if the source was empty.

MoreLINQ is just extensions to LINQ to Objects and in that spirit, it does null argument checking on the source(s) just like all standard LINQ operators. It would be odd and confusing to have code that using MoreLINQ and LINQ in the same query to have a mix of two policies and the reader having to remember when it's okay to send null and when not. Even if you can afford to send null sources to MoreLINQ methods, you would to mask null with an empty sequence before calling the LINQ methods. The best policy is to write functions that don't return null sequences. If you have no control over the source of such functions then the next best course of action is to mask null with an empty sequence early on (when function returns the result) so that each call site is not polluted with null-masking. If source ?? Enumerable.Empty<T>() looks wordy, you can have a single extension method, called MaskNull for example, that hides that and type inference wouldn't even require you to specify the type for T (which is even better than Enumerable.Empty because you can even use it for anonymously projected types).