Separate Foo_Class and Foo_Namespace is definitely wrong, it will prevent you from using Argument Dependent Lookup to find functions in the namespace that are meant to be used with the class.
So the class should be nested within the namespace if there will be functions in the namespace taking arguments of the class type.
Using the same name for the class and namespace is a bit confusing, possibly leading to ambiguities in some cases.
It's also unusual to name a namespace with an initial uppercase letter. If your class names start with an uppercase letter you could go for namespace foo and a class Foo, giving foo::Foo.
Is the namespace not going to contain more than one class? That sounds unusual to me. I would name the namespace after all its contents, just not one type. If it's a socket class I'd put it in a networking namespace, for instance.
I think _c suffixes on classes is completely ridiculous. I don't like the _ns suffix on namespaces either, its only saving grace would be that Foo_ns::Foo is better than Foo::Foo but I'd still make it foo::Foo instead.
(The rest of your question just seems to be "why are namespaces good" which shouldn't really need explaining, they were added to the language for a reason, and the good advice to use non-members for parts of the interface which don't need to be members. Google are right, in general use headers not forward declarations, that doesn't change the fact that you can re-open namespaces in separate headers to add new names to the namespace, which is the advantage you're describing.)