Let me answer the actual question which is:
When it isn't right to add types to a well known namespace?
The question should rather be asking: when it's right to do so because usually it's never right to add anything to well know namespaces. You only do this when you want to use a very specific mechanism.
With this change in mind...
You want to do it when you want the compiler to pick your extension instead of the one provided by the framework.
Example
You might want to use (your own improved) ToList extension that has exactly the same signature as the one in System.Linq namespace. So the first thing you do is to create this:
namespace Company.Linq { public static class MyCustomExtensions { public static List<TSource> ToList<TSource>(this IEnumerable<TSource> source) { ... } } }
But it's very likely that the compiler will refuse to build your project now because it's not sure which ToList it should use.
The call is ambiguous between the following methods or properties: 'System.Linq.Enumerable.ToList(System.Collections.Generic.IEnumerable)' and 'Company.Linq.Custom.ext.ToList(System.Collections.Generic.IEnumerable)'
This means you cannot use System.Linq and Company.Linq (or any other namespace containg this extension) at the same time. This might be a huge problem in case of Linq.
You can resolve it by putting your extensions in a more specific namesapce then System.Linq, e.g System.Linq.Custom.
Now the compiler will choose your extension over the default one because your namespace is more specific.
When there are many of them, it starts to get confusing between what are 'official' types and 'in-house' types.
No it won't, as I've said. You won't be able to build your project if you import extensions with same signatures from two two different namespaces.
You have to decide whether your extensions should replace the original ones or you need to use a different signature. Othewirse there will be conflicts.
