To hit a few points to hopefully help in all this.
The UI:
Beta testing:
Referring back to the whole "Hubitat is a pretty small company" means that they have to rely on user beta testing which is a relatively small group. You're free to enroll though, just shoot a message to @support_team to get enrolled.
The crutch here is that there are just too many variables in user environments to pick up everything in testing. The C-8 is unique, as was mentioned, because they deployed an overhauled ZigBee radio along with a mechanism to migrate ZigBee devices from one hub to a C-8. They do internal testing, do some "alpha" testing with select users, and then ran through beta. Get it to production and folks started having issues. The problem here is that folks have different approaches to implementing ZigBee, specifically with the device types used for repeaters. Much less for end devices. There's just too wide of a gamut of ZigBee devices and chipsets thanks to it's more open platform compared to Z-Wave. You end up with some really weird anomalies that they've been trying to work through.
Testing Functions:
I won't beat the dead horse about time based triggers. They can definitely be used, but putting something on a schedule that runs once a minute will probably result in a bad time (depending on what else you are doing with the rule). Working around this is typically quite simple, but it takes understanding the fundamentals of how things operate.
For something like Rule Machine, my go to is to create an actions list with no trigger. You can manually execute the actions using the "Run Actions" button after installing the rule. IIRC, the other built-in apps limit how they are run, so it's less of a concern.
Another thing to be aware of is virtual omnisensors which can take the place of most physical devices for trying things out.
Dashboards:
The in-built dashboard is really designed for single use. Meaning each tile is a one for one "capability" (like turning a switch on/off) or attribute (like current switch state). Like you found, there are custom drivers out there that this approach isn't really designed around. For something like a device with multiple switches, the typical approach is to create child devices (this is handled at the driver level). These show up under the main device but can function independently. So, you would add the individual children (if available) to your dashboard to manipulate them from there. If those aren't available for a custom driver, you can often drop a note to the developer to request they are created (I do think the Tasmota driver does this).
The names automatically populate based on the display name of the device from the device page. As mentioned, there are some custom local dashboard options out there that allow you to override the name. I use HD+ which was worth the setup time for me since I have tablets scattered throughout the house. It allows (like most others) to setup one dashboard config and to use it as a template for the other devices.
I'm not 100% sure, but there may be some options here with the default dashboard app with CSS customizations. [RELEASE] Simple CSS Editor
General Approach for Community Help:
As you've seen, threads can often get sidelined if there's too many things being discussed. My general recommendation would be to post a single thread for each issue. This helps with the thread staying on topic. I realize that puts more on the user's lap to have to create the various threads, but it goes a long way in helping you get your question answered.
The other piece is to try to provide your generic requirements. I think this was captured well here but goes back to the first point. Try to avoid the XY problem (e.g. posting saying "I want to drive rule execution from Google Calendar" when what you want is to run rules based on a dynamic schedule).
Hope all this helps!
