In terms of the air-gap, if an MCU reboot would reset the device that’d be great and while we are piling on requirements, having the button do some kind of “firmware reset” or “default config reset” that’d be great too. Have it interact with some LED so I know that my button presses are working / received, and document the process, etc. 
Lots of speculation on the snap capability that I’d mentioned earlier. My thought is that sometimes, outlets are in a 2x2 configuration, or whatever you call it, where there are 4 outlets next to each other. Somewhere between rarely and never do folks need the extra amps, what they need are the extra plugs. IMHO, we are trying to shove 15 lbs of electronics in a 5 lb outlet (trying to keep this G-rated), and it seems to me one way to resolve this is to make a “snap on” product that provides extra features and gives you the extra space to shove those electronics to support those extra features.
So, for example, You might have something like this:
Where the “top” two outlets work on Relay A, and the bottom two outlets work on Relay B. These relays and all the embeded electronics would be on the “LEFT” outlet. You don’t need any additional electronics for the “RIGHT” outlet because you are just attaching the outlets to each other (top to top, bottom to bottom). What this gives you is a bunch of space now to shove more electronics that provide more features behind the “RIGHT” outlet. The “Snap On” outlet would be the “RIGHT” outlet and would be a different SKU that would be dependent on the “LEFT” outlet.
Another idea in terms of space, and I’m not an electrician, is that many times outlets are on a stud. It might not be too heavy of a lift for some folks to remove the one gang box and put in a 2 gang box, again, the intent is to give designers the physical space to add electronics and features.
Also, I’d push back on the designers on the Matter/Thread vs Zigbee response, cutting down SKUs and supporting both protocols is going to be important (imho) for the next several years. It will halve your hardware development costs and I think the hardware is going to support both protocols, it’s really a matter of managing the “dual-boot” firmware and having the required storage space for the code, or perhaps use the UART/SPI/SmartCard capability to load new code. If you want to be customer friendly provide connectivity to the UART to load new code. You could use the MCU button for these actions as well.
I wanted to apologize if any of my ideas are previously patented or so forth. I’m not researching my ideas too much, I’m just throwing things up against the wall here, and if they stick, great. I have to say, this is the first Inovelli thread that I’ve contributed on and I’m going to start reading through the other new product threads. This is a great process.
).