Namespaces usage recommendation

I’m used to create a lot of small classes and I want to organize them properly. Namespaces are best way to keep project clean and I believe that only automatization can actually help me) I wrote a script that adds a path based namespace to created C# file but there is a problem. For example, I have a namespace ProjectName.GUI and a class in the ProjectName namespace. When I’m trying to call GUI.Label() compiler throws error
The type or namespace name Label' does not exist in the namespace MH.GUI’. Are you missing an assembly reference?
May be you have recommendations how to organize my namespaces properly?

[tldr]
For games, and for really any other kind of project, there are better methods of dealing with naming conflicts and code organization than just cramming everything into increasingly verbose namespaces.

Some general rules:
-Only use namespaces if you are developing some kind of library code, and only if that code is something that is not used across the whole project.
-Use classes as containers for classes/enums/interfaces/etc to avoid naming conflicts
-If you have to have a naming conflict, use ailiasing to keep it from becoming a problem
-Don’t use namespaces when writing game scripts.
[/tldr]

For video game development, the recommended usage of namespaces is: DONT.

Games are some of the most interconnected software, and it just further complicates things when you have to throw 20 using/import/whatever statements at the top of EVERY SINGLE SCRIPT. There’s no advantage to having to declare imports when plenty of code files in a C# program (especially a game) will be requiring the same binaries to be loaded anyway.

The only time you can really get away with this is if you are writing code that only is ever used in a few places, or helper features you don’t need everywhere, cluttering up your intellisense, or are writing something that gets compiled before/after your game code (Plugin/Editor scripts).

Normal game code shouldn’t go in namespaces, especially if lots of stuff needs to interact with it. Any effects namespaces have on naming conflicts can normally be avoided by using internal classes rather than namespaces, for example:

public class FancyText { 
    public class Settings {
        //Stuff goes here
    }
}

public static class Settings {
    //Game settings stuff here
}

public class DoesSomethingCool {
    public class Settings {
        //Stuff goes here too
    }
}

This is also a better approach to something like naming in @DontShooot’s reply.

public class FSM {
    public class AnimationDependentState { }
}

If you need to use code from somewhere else that is tucked away in a namespace, and you have a conflicting name, you can always alias it if needed.

using Builder = System.StringBuilder;
///<summary> Wraps System.StringBuilder in order to add much needed + operators</summary>
public class StringBuilder {
    public Builder str;

    //...tons of functions that keep all functionality of System.StringBuilder

    public static StringBuilder operator +(StringBuilder sb, string value) { return sb.Append(value); }
    //...etc....
}