Expanding the FCL's System namespace truly a bad practice?

It is common knowledge (and convention) that namespaces are used to uniquely identify code and prevent name clashes, which is why you should always place your own code in a unique namespace as possible.

But, ...

Namespaces are also used to group logically relevant classes together. My personal library simply extends on the Framework Class Library (FCL) and implements all features that I find missing in the FCL. It contains mainly extension and helper classes, and other highly reuseable classes. I found it to be really useful to follow the same structure of namespaces as in the FCL.

I went one step further, and started using the namespaces of the FCL to 'inject' my code into the namespaces where I would actually expect 开发者_JAVA技巧them.

One advantage is that you don't have to define as many usings. E.g. by simply referencing the library, extension methods are immediately available without adding extra usings. As a good example (for those who like to keep their usings list clean), how often do you expect extension methods to work, only to realize you didn't add "using System.Linq;" yet?

UPDATE:

So the main advantage I believe (as mentioned in the comments) is you have access to more utilities more easily without having to look for the specific namespaces. E.g. If you are using System.Collections.Generic, immediately extension methods for IList<T> are available.

I argue that this advantage could actually outweigh the disadvantages. I'm not bothered by the fact that name clashes could occur in the future, as that would indicate a new version of the FCL actually includes something similar as I wanted. It actually makes it easier to notice changes in the FCL, which I would want to reflect in my namespaces anyhow.

Ofcourse, I understand this would go radically wrong if everybody started doing this for public libraries, but for my individual projects I find it truly useful.

Am I overlooking any other disadvantages? I already considered in case I want to make the library public, I need to find a way to either allow using the System namespace, or a different namespace as the user desires. The only way I know of doing this from within the .NET environment is using predirectives.

UPDATE 2:

So, like I said, I do realize some people might find it inconvenient and would desire a different namespace. For my own projects I find it inconvenient to do e.g. the following:

using System.Windows;
using System.Windows.Controls;
using System.Windows.Media
using System.Windows.Media.Media3D;

using MyNamespace.Windows;
using MyNamespace.Windows.Controls;
using MyNamespace.Windows.Media;
using MyNamespace.Windows.Media.Media3D;

Not to mention this problem which makes e.g. using MyNamespace.System.Windows; impossible.

To phrase a question which hopefully results in more useful answers:

Is there a solution to solve this in a better way than placing the code in the System namespace? Is there a way to easily compile to a different namespace when desired, besides using predirectives, or is this a bad idea altogether?

---

Ignoring naming clashes, as you linked to that already...

This has a major advantage that you don't have to define as many usings.

I actually see this as a disadvantage. Forcing you to add a using statement or fully qualify your type makes your code more maintainable, as it makes it more obvious where specific code is defined.

While it may be alright for you to see your utilities in the System.*** namespaces, most developers will expect that a type defined as System.***.SomeType is part of the base class libraries. In my opinion, "expanding" the base libraries with your own types causes confusion, and leads to reduced maintainability.

---

I will post the comment made by Cody Gray that helped me the most as an answer:

Why do you need to separate all of your "helper" functions into separate namespaces in the first place? That is, why can't they call be in MyNamespace, leaving you with only one using directive to add? The only reason namespaces are useful here is to minimize collisions; it's doubtful your extension methods will have the same names (and if they do, you won't be able to import them all at the same time like you've shown anyway).