Bin dafür.
Patch-Vorschlag dafür anbei. Wenn gewünscht, kann ich auch gerne das Gesamtpaket ins svn schieben, aber wie allgemein üblich nicht ohne explizite Anweisung des zuständigen Maintainers.
@Rudi:
Da ist auch ein etwas mehr umfassender Vorschlag für UPGRADE drin. Eigentlich ist das mit den deprecated modules vor allem dann relevant, wenn man neu aufsetzt, und dann nur seine Daten mitnimmt, aber ein besserer Ort ist mir nicht eingefallen.
@hexenmeister:
Danke für die Erhellung bzgl. NodeRed.
MQTT2_DEVICE finde ich nicht unbedingt überladen. Irgendwie müssen halt die Infos in FHEM, und wenn man es mit MQTT_DEVICE vergleicht, sind die lists (bei gleicher Gegenstelle) auch nicht zwangsläufig länger, und auch bei der Kombo MGB+dummy muss die Info "was nach wo und wie" irgendwo hin - das kann halt wildcards, was es an der einen oder anderen Stelle einkürzt. Ähnliches kann man auch mit M2D erreichen, indem man $TOPIC parst, aber das ist eben (in beiden Optionen) nur was für User, die sich (jeweils) etwas tiefer eingearbeitet haben.
Ansonsten ist es erst mal verwirrend, wenn man es mit M2C+autocreate versucht - bei meinen diesbezüglichen Versuchen dachte ich auch erst mal, dass das schwer verdaulich ist (woraus dann das "Sortier-attrTemplate" entsprungen ist). Aus dieser Erfahrung heraus erfolgt auch die Empfehlung, neue Geräte (zumindest erst mal) mit M2S anlegen zu lassen (es sei denn, man weiß, wie das "Sortier-attrTemplate" funktioniert).
M2D ermöglicht es halt, praktisch mit allem irgendwie "fertig zu werden", und wenn das betreffende Gerät seltsame Formate in als Topic-tree und/oder payload verwendet, sieht halt auch das fertige Ergebnis entsprechend aus - aber bisher ging (fast?) alles

. Dieser generische Ansatz (den ja auch MGB verfolgt) ist allemal besser, wie für jede Implementierung "da draußen" jeweils eine eigene "Modul-Sonderlocke" aufzuziehen, wie das XiaomiMQTTDevice oder mein damaliger MiLight-Versuch gewesen waren.
Meine bisherige Erfahrung war, dass alle in diese Richtung gecoachten "Gelegenheitsuser" - nach einer kurzen, teils etwas hoppeligen Einarbeitungsphase - den Wechsel auf die 2-er Module als die richtige Entscheidung bestätigt haben. Die haben aber in der Regel nicht so das große Interesse, umfangreiche Systemlandschaften mit verschiedensten Lösungen zu pflegen

.