Should I use (otherwise optimal) class names that conflict with the .NET BCL's names?

Question

This situation probably is not entirely uncommon to some of you: you have some functionality to put in a class but the perfect name (*) for that class is taken by one of the classes in the System namespace or other namespace/class that's not yours but you're using/importing.

(*) By perfect I mean small, concise and clear names.

For instance I have an Utils class that has a Diagnostics (mostly debug utils) class and a Drawing class. I could:

1. have a DrawingUtils class and a DiagnosticsUtils class, but that just smells like bad structure.
2. pick a thesaurus and be done with an worse, longer or awkward name that's casually still not taken.
3. Write class names in my native language instead of English.
4. Ask the smart guys at StackOverflow.

I think options 1-3 aren't promising :(

EDIT:

Since my chosen answer doesn't address the problem definitively (neither I do), what I'd recommend for people facing the same situation is to ask yourselves: Will you frequently use the conflicting BCL class/namespace? If no, then let your name conflict (as I did with Diagnostics). If yes, add a word that limits the possibilities of your class/namespace.

In practice, this means:
"Drawing": Something that draws.
"MyCustomControlDrawing": Something that draws only on MyCustomControl. e.g.: "WidgetDrawing".

EDIT2:

Another solution to take a look next time: Extension Methods (courtesy of Lawnmower).

Answer 1

Use namespaces to disambiguate your classes from the classes in other namespaces. Either use fully qualified names or a using statement that tells the compile what you need:

using Type = MyReallyCoolCustomReflector.Type;

Now if you want to still use the Type class from the System namespace:

System.Type sysType = anObject.GetType();

Generally I try to avoid name duplicates but this doesn't always work out that way. I also like simple, readable and maintainable code. So as often it is a trade-off decision.