What are use-cases and/or pros and cons of having a named namespace within an unnamed namespace?

Question

The following "named namespace within unnamed namespace" scenario is allowed (as I understand it):

namespace foo {
    namespace {
        namespace bar {
            int baz() { return 42; };
        } // bar
    } // unnamed

    int frob() {
        return bar::baz();
    }
} // foo

int froz() {
    return foo::bar::baz();
}

Is applying this considered a pattern / an anti-pattern (compared to not having the bar namespace within the unnamed namespace)? Are there any use-cases (beyond the ones below) for using such a namespace within an unnamed namespace?

The following use-cases came to my mind, which are somehow unusual and don't represent the "everyday" way of coding:

• In an existing namespace hierarchy, say, a::b::internal, with stuff from internal only being used in the same translation unit, adding an unnamed namespace "in between" like a::b::<unnamed>::internal does not break existing code that explicitly refers to the internal sub namespace.
• If there is lots of stuff in the unnamed namespace you might want to have some sub-structuring. (Maybe you better re-design your file-structure...)
• When bringing together different parts of source code within the same namespace in the same compilation unit by #includeing them, this might allow some hacks - I myself, however, could not even think about something here that could not be solved nicely without that feature.