@GraphicHealer Forgot you mentioned that you haven't gotten the hubitat yet. When you get it and need help getting this stuff set up, feel free to reach out. 
Gary, where do I begin? The 3-way is easy, so I guess I'll start there. Keeping it simple, I made a copy of the single relay driver and made it so that the on/off commands are always sent to "Power2" (the A/B relay) via a "toggle" command, and that the syncTasmota stuff listens for changes in Power1 (the load-sensing relay). Hub UI updates with the actual load status, and tapping it or telling it to turn the thing on or off will always switch the relay via a toggle command. ... As I'm typing this, I realize that probably will become problematic if a light is already on and the hub sends another on command, it will then toggle Power2 and thus turn the light off.... hmm. Need to play with that more. I was just happy I got it to stop "rave party"-ing and the UI was updating appropriately.
As for the other device, I'll try to keep it simple, but it was a very lengthy process. I basically swapped out bits and pieces of your driver to accomodate the TuyaMCU stuff. "FANSPEED" commands going to tasmota became TUYAENUM4 (props to Obi2000's driver for that little discovery that TuyaSend4 wasn't necessary; it simplified things), changed power1 and power2 accordingly so dimmer commands would stop turning on the fan power toggle, learned what SetOption20 was so as to ALWAYS send the "power2 on" command along with a dimmer change (power2 is defaulted to the light, but changed to the fan so the driver on/off buttons change the light), etc. Also wrote a dedicated "rule1" that followed your "rule3" template so that any change in TuyaEnum4#State>0 DO Power1 1, state==0 DO Power1 0, etc. etc. AND, set up the driver so that the "tasmotainject" sends in rule1, rule3, turns on both rules, and enables SetOption20.
All of this was done over the course of hours and hours over multiple days, essentially reverse engineering your code and educating myself on how it works, what variables are getting sent where, tweaking the rule3 format to fit my specific needs, etc. Sidenote, I even tried to set up separate dimmer and fan devices, writing two versions of the code to focus the switch operations on the dimmer relay and the other on the fan, only to get greeted with the "a device already has this DNI, change it" message in the logs. Doh!
The end product is a single device that receives all power relays, dimmer state changes, and fan speed changes via integers and converts them to the necessary speed strings, including power2 "off" going to the fan control in the UI flawlessly. Local operation sync, remote operations do not race, everything is great.
... Enter the assistants. Alexa and Google ARE NOT down to clown with this combined driver capability. Alexa can't figure it out at all, Google turns on the light at 13% when told to "set the living room fan to low" and it's just a clunky mess. So, I created a virtual fan that will be exposed to the assistants. I used Ryan's fan sync app to translate assistant to virtual, which then pushes the virtual device changes to the actual switch. A rule machine rule that starts with any change in fan speed on the physical switch pushes the corresponding change to the virtual fan, that is then reflected in the assistants, thus 2-way syncing there as well (Turns out I can make a second instance of Ryans app with the slave fan as the master fan to create two 1-way bridges between them, saving me a rule machine entry for each room. * face palm *) (another side note, I wish that "fan speed" stuff in rule machine could play with variables. It's a bit of a pain to create 4 conditional actions to react to each POTENTIAL fan speed, when a single command with a variable would consolidate it much nicer). For the dimmer, I just used the built in groups command to add the Fan/Light controller to a "dimmer group" of one, then exposed the "group as a device" and included the group state, then shared THAT device with the assistant. Group updates with the local switch changes, sends that to assistants, which can 2-way speak that back to the actual switch via the group, so that was easy.
I'll squirrel this whole thing away for when somebody else might need it, but being that the DS03 stopped shipping with "Tasmota-able" chips a while ago, I don't foresee this needing much attention. But for those that do, I'll be happy to share my notes.
As always, thanks again for being the springboard to launch me off on this project. It's been a lot of fun (albeit frustrating at times) and I couldn't have moved "everything onto the hub" and thus pulling out the node-red / MQTT middleman without it.
