So here's a very persistent device:
That I cannot seem to get rid of.. I tried a soft reset, power-off reboot, refresh/discover/remove. Nothing clears it. Also fun is it's not showing on my secondary controller (which is ID 35).
It's a reverse ghost??? 
Does it persist after a shutdown and power removal? Thinking maybe it is cached in the ZWave radio, but not actually in the ZW-database.
Yep unfortunately it does..
Maybe try removing and re-adding your secondary controller in case it stopped receiving updates for some reason, then see if you can use that method to remove the possible-ghost node?
The error message you see can be (maybe just "is"?) the result of Z-Wave database corruption, and there were some changes made around 2.2.9 that should address that going forward--I think SiLabs started using a standard/common database format instead of their own. However, it won't help with anything done in the past. If the secondary still doesn't show it, then...I don't know, but I guess it might support the corruption theory. 
Yes did that too - tried different secondary controllers including another UZB-7 (with updated firmware) and a Z-Stick. It's very strange.
Even created a device and assigned the DNI to try and remove it.. that did not work either so recreated the device and have left it that way as a visual placeholder. Don't know what else to do.
I'll check with @bobbyD and see if I can do anything - I may have to do the migration thing + ZW reset. I wonder if it can be done "in place" with same hub.
You have so much free time, perhaps you should just reset your Z-Wave radio and rebuild from scratch. Need to keep those skills fresh.
Honestly, I recently did this myself after I noticed what I assume was corruption in my longstanding C-7 database (the issue that 2.2.9 and later should make it easier to address going forward but won't help with existing databases). I was shocked at how smoothly it went. I've used three C-7 models, including one of the very first, and honestly the process was quite painful then; it seemed every few inclusions would fail, give an error/warning in the logs, or just not work for some reason. This was improved a lot within the first few firmware versions, probably with a radio firmware update or two also helping.
To make it "easy" on myself, I just bought a replacement C-7 (instead of resetting my existing hub and being with nothing until I finished) and re-paired everything to it. To my shock, my only failure of about 40 nodes was a single battery-powered device that likely just ran out of battery when re-pairing. I was able to remove that failed pairing and try again. I still used a secondary controller to get some S0-only devices in without security (probably won't buy Monoprice Z-Wave again, but I already have them so 
).
So, I'm not saying it's fun, but for me I think it was worth it in this case to get a clean Z-Wave database in the new format (not sure the current firmware works with either format or upgrades yours, but I do know they've said it won't fix any existing problems, so I'm guessing the former). And it made me much less hesitant about Z-Wave than I've been since the introduction of 700-series controllers!
Difficulty: client's hub 
Does a hub migration correct ZW Table issues?
I haven't seen confirmation either way, but I doubt it--we know that it doesn't correct other problems but just copies them along, so I don't have any reason to suspect this particular issue is any different.
I've emailed support for their advice as well. Will report back.. but suspect the same answer.
Since all my logic is in Node-RED I won't have to rebuild my rules or do any DNI trickery.
I am pretty sure I recall @bcopeland mentioning that once there is corruption in theZ-Wave SDK’s database, that corruption will be migrated when using Hubitat’s Hub Protection Service.
Yeah that does sound familiar..
I know what I will probably have to end up doing, just not happy about it. 
I will also probably also swap out the existing hub for a new one.
Download the Hubitat app
