A few days ago here on the mailing list, a person posted that some
programmers are avoiding doing:

    typedef vector<int> IntVec;

and instead are doing:

    class IntVec : public vector<int> {
        . . .
    };

simply because the former gets mangled to something horrible, and the
latter gets mangled to something that is easy to spot in the debugger.

The C++ Standard doesn't mention the word 'mangle', however it is at
least on some level aware of mangling because you can write "extern C"
to tell the compiler not to mangle a name -- or at least to mangle it
the way it would get mangled if it were C instead of C++.

I thought about this for a little while just now, and sadly I'm unable to see anything sensible for this to mean.

Suppose — the simplest behavior I could think of — suppose we just want that `asm` attribute to cause the compiler to somehow pretend that the name `A` is merely a typedef for a class whose "true name" is `Beta`. That's still very confusing and unhelpful, because are we saying that the "true name" doesn't contain any namespaces? If we wanted it to be namespaced, how could we possibly encode that? Notice that naming an actual entity doesn't run into this problem, because the string in the `asm` attribute ends up encoding the entire symbol name, not just a piece to be further mangled later.
namespace Nano {
  struct A asm("Beta"); // fantasy syntax
  struct A {};
  int f(A) { return 0; }

    // Today: _ZN4Nano1fENS_1AE

    // Tomorrow: _ZN4Nano1fE4Beta ??
}

What if the original typedef could be rewritten as:
        typedef vector<int> IntVec <=> mangle("IntVec");