typedefs of QString with Q_DECLARE_METATYPE can not be viewed via QSignalSpy

typedef QString FooBar;
Q_DECLARE_METATYPE(FooBar);

class MyClass : public QObject {
    Q_OBJECT
signals:
    void test(FooBar baz);
};


QSignalSpy *spy = new QSignalSpy(myClassPtr, SIGNAL(test(FooBar)));
FooBar baz = "myValue";
emit myClassPtr->test(myValue);

QList<QVariant> arguments = spy.takeFirst();
Q_ASSERT(arguments.at(0).type() == QMetaType::type("FooBar")); // okay
FooBar test = arguments.at(0).value<FooBar>();
Q_ASSERT(test == "myValue"); // FAILS, test is == ""

The problem is that the following fails:

Q_ASSERT(qMetaTypeId<FooBar> == QMetaType::type("FooBar"));

It fails because the qMetaTypeId<FooBar> returns 0x0a: the metatype for QString. This makes sense because the FooBar type really is the same as QString.
But QMetaType::type("FooBar") does the lookup from Q_DECLARE_METATYPE and returns the user-type for it (in my case 0x0110).

So, I think the fix is to have Q_DECLARE_METATYPE check first if the true type is already registered or not. It is not possible to use the type name (as all we have is FooBar), and we can't use qMetaTypeId() because that won't work unless if it is already registered, which may or may not be true. So, I think the solution is to have QMetaType::registerType(name, deconstructor, constructor) check if the deconstructor/contructor match any already-registered types. If so, make it an alias of the already-registered type; otherwise register it as a new type.

The problem will affect more than just the signal-spy. It will affect any time that a QVariant is based on the type name ("FooBar") instead of using the actual type (T). So, perhaps queued signals and slots are affected?