I don't understand why you would ask me that. You just said that you didn't want to hear me complaining . You asking me that is like asking Hannibal Lecter to cater your party and then being annoyed by what's on the menu. I wouldn't do anything other than fight with Markus about his approach to one device (and by this i mean model of device) = one driver. That isn't the right way to do this, in my opinion. I wasn't as forceful at first but after Mike Maxwell made the exact same comment later on, I decided that maybe I was right after all.
The best way to handle Tasmota devices, from a usability perspective, is to have have the user create the parent device and then have that device create children as it receives information from the physical device. If it receives a switch 1 status, it creates switch 1. If it receives energy meter 1 info, it creates energy meter 1. If it receives switch 2 status, it creates switch 2. And so on. This would mean you would only have to create and maintain 1 parent driver and then 1 each of the child drivers for the number of capabilities that the devices support. So, one each for switch, power meter, dimmer, rgbw, etc. That takes the responsibility out of the hands of the user to figure out what drivers to use. It does make the user configure their Tasmota device, but since the templates site pretty much gives that information directly to you for every device it supports anyway, that's not really an unreasonable expectation. The requirement that the Hubitat driver setup and configure the Tasmota device is unnecessary in my opinion and creates way too much complexity. It does not really gain you anything. It also means that you are going to have to end up having one driver for every variation of template that the Tasmota devices have.
Look at it this way...Tasmota didn't wan to have the user create a different firmware for every device, right? So, they create a means to configure the firmware for the capabilities of the device. That same model should be used in Hubitat. Don't make the user pick the driver for the device. Let the driver be build in such a way as to work with any device and let the configuration be dynamic depending on the device in question.
@markus thinks that the only way to do this is dynamic commands and capabilities. When told those weren't a thing his reply was
I want them to work that way
That, to me, is not learning to develop for the platform. That's like showing up at a basketball court where everyone is already playing and saying "New rule, you don't have to dribble" and just expecting everyone to capitulate. He had no interest in hearing what people who have had the system for a lot longer or people who work for hubitat had to say about it.
In it's current formation, these drivers are not sustainable. You already have over 50 of them. Are you going to make one for every device listed on the tasmota templates page? That's a lot of wasted effort, IMHO.