All my drivers clear the "State Variables" and some "Data" values during configure because, like you, the old stale info from other drivers annoys me.
Typically attributes are fine because if they are not defined on the new driver, they usually go away. If they are being stubborn I use the trick with the "Device" driver.
That is true, HE does natively remove "Current States" attributes not covered by the current driver.
That's not what I'm observing with the Zen31 driver. If first i set it to Zoon RGBW and then set a color...I get states like "RedLevel" and "Green Level". Those dont go away after switching to Zen31 Advanced and configuring.
I think those are in the "Current States" to the right side, not the "State Variables" which is below the commands. They are supposed to go away if the driver does not have them defined, but like I said sometimes they get stuck.
I could probably add to my standard cleanup function to clear those as well, I don't remember if there is a built in function or if I would have to do a loop and clear each one.
If only there was something built-in you could call.... 
I'd take it one huge step further than that.
Most of those who are writing drivers and apps are doing an incredible job with their efforts. They are doing the best they can with what they are provided by the HE platform.
My guess it they would be onboard with an effort to push the platform forward and deal with issues like this one you are pointing out. There is a long list of details like this that need to be addressed. Until their is an effort to address this type of usability issue, home automation is going to remain a hobby type of thing because it's just not ready for the average joe.
Seems like the perfect place for a kick starter type of thing where developers along with the HE team could work together and push things forward and make some well earned profit from their efforts.
@kkossev has taken a small step as a 3rd party to push things forward around device health. This is another one of those little details that is important and needs to be clarified and then exposed throughout the Hubitat UI.
It does seem like nowadays we get on top of soap kick-starters... They are all packed in cardboard nowadays.... Not all can withstand the weight of us who have something important to say.... Particularly those like me who have accumulated some "soap" along the way....
You say that like it is a bad thing.... I would disagree. 
I would agree that some of the adjustments users need to make in their setup are complicated in nature, but that doesn't mean they need they to be complicated for the user.... Some, if not all, of that complexity can be handled by the developer.... I'm not suggesting I can cater for all these complexities as a developer myself, but am willing to have that onus put back on me...
It could be a very bad thing for Hubitat. As home automation grows with Homekit and Alexa, and soon "Matter Devices", if a platform like this is not simplified over time, it will fail to capture the growing market and possibly become unsustainable.
I'd be wary of turning this feature request into a discussion about broader issues.... There may be things the Hubitat team need to consider re broader HA trends, but this request can still gain traction without introducing these broader issues.... Not to say they aren't worth discussing...
I'd take this and run with it as the headline act.... Which I support.
True. Or it could survive, and even thrive, in its own little niche and not care about growing or dominating.
If you can't tell, I'm definitely not a "if you're not growing, you're dying" businessman.
But whatever, I'm not losing sleep over it either way.
A few years ago, Steven Stroud (@BorrisTheCat) posted a simple driver that does what you want. It’s rather easy to modify it to only do what your use case needs.
https://raw.githubusercontent.com/borristhecat/HUBITAT/master/Drivers/Clean%20Device.groovy
I only used it a couple of times a few years ago.
Edit: Seems the link is no longer good. Here is the code:
/*
* Device Type Definition File
*
* File Name: Clean Device.groovy
* Author: Borristhecat copyed some code from Fibaro UBS from ST by Chris Charles
***************************************************************************************
*/
metadata {
definition (name: "Clean Device",namespace: "BorrisTheCat", author: "Steven Stroud", importUrl: "https://raw.githubusercontent.com/borristhecat/HUBITAT/master/Clean%20Device.groovy") {
//capability "Configuration"
command "WipeState"
command "ClearSchedule"
command "removeChildDevices"
}
}
//def configure() {
// WipeState()
//}
def WipeState() {
log.warn "wiping states"
state.clear()
}
def updated() {
log.info "updated()"
}
def ClearSchedule(){
log.warn "Clearing schedules"
unschedule()
}
private removeChildDevices() {
log.info "Removing Child Devices, if any installed"
try {
getChildDevices()?.each {
try {
deleteChildDevice(it.deviceNetworkId)
} catch (e) {
log.debug "Error deleting ${it.deviceNetworkId}, probably locked in a App: ${e}"
}
}
} catch (err) {
log.debug "Either no children exist or error finding child devices for some reason: ${err}"
}
}
There used to be @discobot, whom you could ask how to insert code, but he seems to have disappeared, replaced by @hubby, who says he is dumb and doesn't know how to answer questions. Took a bit of experimentation.
Edit2: fixed the link. Seems that Steven Stroud reorganized his GitHub repository.
as a dabbler with drivers - I'd like to chime in some experiences - I learned about the 'driver' swap trick a long while back by per accident. I can't exactly remember how, but it was deeply buried I do recall.
I am fairly certain it fails to remove Preferences. Its actually on my list of things to do this week - to write something. I've been testing a driver from a hot new dev and one problem has been switching the driver out leaves behind values and potentially nulls stored which in turn causes his updates to fail as well. The solution was to pull the device from HE which is a stupid step considering. But the Driver driver isn't public, so I don't think it can be modded or looked at so, who knows for sure except ...
Regarding the idea of modding all drivers so that Configure starts the slate clean, it should be a function of the HE. When you pick a new driver, it should blow out all the values at that moment. Schedules, States - all that should drop at that moment. In fact, changing the driver shouldn't be a part of 'save device'. It should be seperate and the functions of Driver driver should be built into HE in a 3rd section 'Driver'. So Preferences, Device, Driver sections. Then debugging and control are taken from the obscure to the forefront. it is here that 'Debug', Trace and Warn should reside as well as the 'clears' so clear (dropdown), logs, children, states, schedules,preferences etc.
I just compare what has been learned on other platforms (not just the ST, but look at what Tuya's doing EG) my 2 cents.
My gut feel is you are still in favour of improving the platform, like @jercloud, it's just some of the intent may be lost in the words... Or maybe that's the dying vs growing mentality... Growing is a subjective assessment.... And maybe you're not seeing growth in this request.... all good, and like you say....
Sweet dreams
@627southmain - was really interested in that link! Please do post it or your copy of the code?
See above.
It does feel like the original post seems the simplest in terms of what we can request of HE developers, please clear the attributes when the driver is changed. Preferences seem like a late addition, but one I would also support.
I very much am. I just don't get super passionate about features that seem to be fringe/that a minority want.
It is cool for them to want them and ask for them, of course! And I encourage them to do so.
So anyway, I'll bow out of/mute this. I don't want to detract (any more than I already have!) from the perfectly valid feature request.
Download the Hubitat app
