Под "кошерностью" в данном случае понимаю строгое следование документации Qt.
Но раз они сами себе позволяют ей не следовать и у вас
то и спорить в общем-то не о чем.

А откуда такое обилие? Они что, не укладываются в единый интерфейс/класс плагина или как?

Провел эксперимент.
Если убрать макрос Q_DECLARE_INTERFACE, то проект плагина (я взял проект хокса для тестов) не компилится.
Ругается, что у интерфейса нет макроса Q_OBJECT. Если его добавить, то ругается, что не может преобразовать интерфейс к QObject *
Дальше добавляю наследование от QObject. И больше не ругается. И плагин компилится.
Хоть использовать его и нельзя, т.к. макрос Q_DECLARE_INTERFACE определяет какие-то функции, которые видимо необходимы метаобъектной системе, и без него система работать не будет.
Отсюда я делаю вывод, что интерфейс в Qt имеет все-таки метаобъектную природу и рассматривается метаобъектной системой как QObject.
Таким образом интерфейс в Qt не равен чистому интерфейсу c++. Moc используя макросы его "тюнингует".
И отсюда главный вывод, что использование сигналов в интерфейсах Qt допустимо.

PS. что делает сам макрос мне не очень понятно. Определяет какие-то функции. Мне не понятен синтаксис препроцессора.

C++ (Qt)
#  define Q_DECLARE_INTERFACE(IFace, IId) \
    template <> inline const char *qobject_interface_iid<IFace *>() \
    { return IId; } \
    template <> inline IFace *qobject_cast<IFace *>(QObject *object) \
    { return reinterpret_cast<IFace *>((object ? object->qt_metacast(IId) : 0)); } \
    template <> inline IFace *qobject_cast<IFace *>(const QObject *object) \
    { return reinterpret_cast<IFace *>((object ? const_cast<QObject *>(object)->qt_metacast(IId) : 0)); }

Ну "в общих чертах" да, но сам бы такое я написать не смог. Что такое template <>  

Хмм.. ну а тогда в чем смысл плагинов что обычно подразумевает расширение возможностей без изменений хоста? Не лучше ли делать это статик либой, возможно вынося в плагины только независимую часть (как советует  xokc) пусть и недостаточную для поддержки "всего".

15 различных типов - камеры, видеокоммутаторы, устройства отображения и т.д. И в каждом типе может быть 1-10 различных конкретных железок, напр. камеры от sony, axis, polycom и т.д.
Чтобы было понятнее опишу суть проблемы детальнее. Есть набор различного оборудования которым надо управлять, оборудование это различных типов, и различных вендоров в пределах одного типа. Все это оборудование образует единое целое - мультимедийная студия, которой необходимо управлять целиком. Таких студий с различным набором железок много, и моя цель - написать программу, которая будет брать из конфига список оборудования, характерного для данной конкретной студии и имея интерфейсы к типам устройств и плагины для каждой конкретной железки управлять ими всеми. Причем этой самой программе не нужно знать что есть конкретные железки, скажем камера Sony EVI HD 7, ей достаточно знать что есть интерфейс CameraInterface и получив из конфига имя плагина для данной железки создать экземпляр класса который будет ею управлять. В таком случае для адаптации к конкретному набору оборудования необходимо будет только создать соответствующий конфиг и дописать необходимые плагины для железок, изменения самой программы не потребуется.

О спасибо! А то не нашел.

Полная находится в qobject.h

C++ (Qt)
template <class T>
inline T qobject_cast(QObject *object)
{
#if !defined(QT_NO_QOBJECT_CHECK)
    reinterpret_cast<T>(object)->qt_check_for_QOBJECT_macro(*reinterpret_cast<T>(object));
#endif
    return static_cast<T>(reinterpret_cast<T>(object)->staticMetaObject.cast(object));
}
 
template <class T>
inline T qobject_cast(const QObject *object)
{
#if !defined(QT_NO_QOBJECT_CHECK)
    reinterpret_cast<T>(object)->qt_check_for_QOBJECT_macro(*reinterpret_cast<T>(const_cast<QObject *>(object)));
#endif
    return static_cast<T>(reinterpret_cast<T>(object)->staticMetaObject.cast(object));
}
 
 
template <class T> inline const char * qobject_interface_iid()
{ return 0; }
 

Если, конечно, я правильно все понял.

Не думал что придется возвращаться к этой теме, но пришлось - при попытке добавить наследование интерфейса от QObject получаю ошибку при сборке плагина QObject is ambiguous base of [имя плагина]. Насколько я понял компилер не знает какой из конструкторов QObject ему использовать. andrew.k подскажи как ты решал эту проблему?
Интерфейс:

C++ (Qt)
#ifndef TESTINTERFACE_H
#define TESTINTERFACE_H
 
#include <QObject>
 
class QString;
class QStringList;
 
class TestInterface : QObject{
    Q_OBJECT
public:
    virtual ~TestInterface() {}
    virtual QStringList operations() const = 0;
    virtual QString operation(const QString& strOperation ) = 0;
signals:
    void operationSelected(QString oper);
};
 
Q_DECLARE_INTERFACE(TestInterface, "ru.prog.PluginTest.TestInterface/1.1")
 
#endif // TESTINTERFACE_H
 

Плагин

C++ (Qt)
#ifndef FRUITS_H
#define FRUITS_H
 
#include <QtCore>
#include "fruits_global.h"
#include "../TestInterface.h"
 
class FRUITSSHARED_EXPORT Fruits : public QObject, public TestInterface {
    Q_OBJECT
    Q_INTERFACES(TestInterface)
 
public:
    explicit Fruits(QObject *parent = 0);
    virtual ~Fruits();
 
    QStringList operations() const;
    QString operation(const QString &strOperation);
 
signals:
    void operationSelected(QString oper);
};
 
#endif // FRUITS_H
 

C++ (Qt)
#include "fruits.h"
#include <QDebug>
 
Fruits::Fruits(QObject *parent) : QObject(parent)
{
}
 
Fruits::~Fruits()
{
 
}
 
QStringList Fruits::operations() const
{
    return QStringList() << "apple" << "grape" << "banana" << "kiwi";
}
 
QString Fruits::operation(const QString &strOperation)
{
    emit operationSelected(strOperation);
    if (strOperation == "apple") {return QString("i'm a Apple");}
    else if (strOperation == "grape") {return QString("i'm a Grape");}
    else if (strOperation == "banana") {return QString("i'm a Banana");}
    else if (strOperation == "kiwi") {return QString("i'm a Kiwi");}
    else {qDebug() << "unsupported operation"; return QString();}
}
 
Q_EXPORT_PLUGIN2(TestInterface, Fruits)