Superiority of unnamed namespace over static?

How are unnamed namespaces superior to the static keyword?

You're basically referring to the section §7.3.1.1/2 from the C++03 Standard,

The use of the static keyword is deprecated when declaring objects in a namespace scope; the unnamed-namespace provides a superior alternative.

Note that this paragraph was already removed in C++11. static functions are per standard no longer deprecated!

Nonetheless, unnamed namespace's are superior to the static keyword, primarily because the keyword static applies only to the variables declarations and functions, not to the user-defined types.

The following code is valid in C++:

//legal code
static int sample_function() { /* function body */ }
static int sample_variable;

But this code is NOT valid:

//illegal code
static class sample_class { /* class body */ };
static struct sample_struct { /* struct body */ };

So the solution is, unnamed (aka anonymous) namespace, which is this:

//legal code
namespace 
{  
     class sample_class { /* class body */ };
     struct sample_struct { /* struct body */ };
}

Hope it explains that why unnamed namespace is superior to static.

There's an interesting problem related to this:

Suppose you use static keyword or unnamed namespace to make some function internal to the module (translation unit), since this function is meant to be used internally by the module and not accessible outside of it. (Unnamed namespaces have the advantage of making data and type definitions internal, too, besides functions).

With time the source file of the implementation of your module grows large, and you would like to split it into several separate source files, which would allow for better organizing the code, finding the definitions quicker, and to be compiled independently.

But now you face a problem: Those functions can no longer be static to the module, because static doesn't actually refer to the module, but to the source file (translation unit). You are forced to make them non-static to allow them to be accessed from other parts (object files) of that module. But this also means that they are no longer hidden/private to the module: having external linkage, they can be accessed from other modules, which was not your original intention.

Unnamed namespace wouldn't solve this problem either, because it is also defined for a particular source file (translation unit) and cannot be accessed from outside.

It would be great if one could specify that some namespace is private, that is, whatever is defined in it, is meant to be used internally by the module it belongs to. But of course C++ doesn't have such concept as "modules", only "translation units", which are tightly bound to the source files.