Pavel K

Тынц: https://doc.qt.io/qt-5/qml-qtquick-shapes-shape.html (Через PathSvg можете вывести непосредственно сам путь из svg "" .
Анимировать/изменять/взаимодействовать можно относительно легко.

Но тут, как обычно, есть много НО:
1. Вам придётся все стили: обводку, заливку, градиенты прописывать вручную у Shape (как в примере по ссылке)
2. Взаимодействие - на Shape целиком. Нужно на отдельный путь - извольте его в отдельный Shape засунуть
3. ТОРРРМОЗЗЗа, т.к. для ровности и плавности нужно выставлять layer.samples: 16 (минимум). Особенно заметно, если планируете под мобилки. Как статичный интерфейс ещё потянет, если Вы вдруг собрались его делать.
4. Пляски с маштабированием и размерами (У Shape scale появился только с 5.12 вроде)
5. Если у путей стоит какой transform (Иллюстратор его любит выставлять где не приколочено), то либо его то же прописываете (и увеличиваете тормоза), либо сразу применяете к path.d, но для этого придётся писать свой парсер (т.к. трансформации могут быть и на группе то же и на svg целиком), причём достаточно нефиговый - по себе знаю :D
6. Далеко не все возможности SVG реализованы в явном виде. Некоторые поддаются "костылянию" (через ShaderEffects, либо через написание собственных фрагментных шейдеров в крайнем случае. Например - clipPath придётся делать через OpacityMask либо бить дизайнера, что бы обрезал сразу), что опять же увеличивает тормоза.

Опишите для чего именно Вам нужно, подскажу конкретнее куда копать. Может проще вообще в сторону наследования от QQuciPaintedItem и всю работу доверить QSvgRenderer.

Вообще чисто теоретически это возможно, но с ограничениями из-за принципа метасистемы Qt, а именно она регистрирует каждый тип под своим номером, а потом, когда нужно, на основе этого номера создаёт сам экземпляр класса.
То есть можно подменить, что бы при создании интерфейса создавать вместо него сам класс, но тогда вы не сможете использовать интерфейс "в прямом" его понимании, т.е. использовать множественное наследование, т.е. один класс, один его интерфейс всё. Хотя может быть да же и это можно обойти, если хорошо покопаться в метасистеме т.к. я внутренности смотрел не слишком пристально, но то, что возможно, это точно.

UPDT1: Пардон, всё уже придумано до нас: pavelk.ru/ispolzovanie-interfejsov-klassov-v-qt-i-qml

Напрямую из qml - никак, придётся Вам обращаться к c++.
Пример класса есть тут.

Оба Ваших подхода - костыли.

Для этого есть Q_PROPERTY, если вкратце - наследуете Ваш класс от QObject, прописываете Q_PROPERTY, например field1, дальше в QML

Item {
 id: myForm
  objectName: "myForm"
 property var formHandler;
 
 TextIntput {
    id: textInput1
   onEditingFinished: {
      formHandler.field1= textInput1.text; (textInput1 можно отбросить и написать просто text)
   }
 }
}

Находите через findChild "myForm", устанавливаете ему через QVariant::fromValue(myFormHandler) инстанс класса обработчика. Таким макаром при завершении редактирования текста Вы в c++ классе автоматически получаете актуальное значение. Дальше, для сохранения значений, например в базу, можете прописать в слотах какую-либо функцию, например saveForm(); и в QML по нажатию кнопки её вызывать: formHandler.saveForm(); и уже ничего ниоткуда собирать не надо - всё будет в прописанных Q_PROPERTY.

P.S. Это лишь один из вариантов =)

Так, этой баге уже 3й год пошел https://bugreports.qt.io/browse/QTBUG-36895