After initial discovery of z-wave device the "Edit" button on the DNI field is not present. A reboot of the hub is required to restore button.
I'm in the tedious process of re-discovering all of my z-wave devices (74!) and am following the process of adding device and then transferring DNI over to existing device. Adding an extra reboot after every few additions is one more pain point to the process. The Edit button is available on the older existing devices but is not present on any of the new adds until reboot.
While the issue you noted may still stand, the process you are referencing above should no longer be necessary; the new(er) Swap Apps Device feature will basically do this for you, without the need to manually edit DNIs, and the limitations are basically the same (e.g., no child devices). That being said, I suppose there is still a need to make sure the DNIs don't conflict, which might be an issue if you're doing this on a reset radio or after restoring from a backup...
Has there been any discussion of providing a quicker way to remove the old zwave device? Some sort of "expert mode" or "skip hub exclusion" setting???
I've been bitten during the removal by a family member switching a light while I'm removing a defunct zwave device (ie DNI set to Bxx). The hub removed that device and caused much more work to recover.
I have not seen any talk of that. However, I do seem to recall some cases where the hub just removed the device and skipped the regular Z-Wave exclusion attempt... I think. I don't honestly remember when, but reasonable guesses are when the Z-Wave Details table has no matching node ID (by hex, sans 0x, and not decimal) or when the DNI isn't valid hex at all. It might be different between a C-5 and C-7. Sorry, I'm not much help there...ha.
But normally doing "Remove Device" on the device detail page would be a node-specific exclusion. I suppose the hub might do odd things if it doesn't think it knows that node (or it's not a valid node ID and my guess above is wrong). A general Z-Wave exclusion from the Z-Wave Details page or Add Device page would certainly do what you're describing.
I've never been a fan of Z-Wave devices where the inclusion/exclusion process gets started by doing something you'd normally do in regular device operation, like tapping the switch on or off, but that's another story... (but fortunately, a lot of mine require a triple tap or other less likely combination).
The Zwave removal from what I understand is out of the hands of Hubitat devs, they can only provide an interface to invoke the tools provided by Silicon Labs in order to be a certified hub.
Couple of suggestions though, you could try doing a factory reset and Zwave replace instead of excluding and pairing again. This was written for Zooz but could apply to any zwave device: [Guide] Updating Firmware and ZWave Replace
You could also factory reset the device, then from zwave details refresh until you get the remove option, then remove the device. Supposedly it helps if you remove power from the device so there is no chance it replies back, but IMO if it is properly factory reset it should not reply.
I've had moderate success with the replace option. It's quite useful when one device stops working. When doing a migration or a full redo of devices, having a process that doesn't take long for each device is really desirable.
What I'm suggesting is to skip the zwave removal process after using the Swap App or edit DNI procedure when the device's DNI is out of range of known zwave devices. Why invoke the remove process on the zwave system when you know in advance that there is no device to remove?
Granted, you don't want users creating ghost devices by removing DB entries when the zwave device also needs to be removed. But the scenario after a reset of the zwave radio and then editing every zwave device DNI by added a 'B' to the beginning to indicate they are out of range. Now as each device is added, run Swap App, and then delete old device. The old device at this point is only a DB entry with no references and no active zwave device.
(My zwave network has been getting several daily "Network busy" errors and some devices are then not switching. I've got 80 zwave devices and setup nearly every one with S2 security so I'm doing a full reset and rebuilding without S2, except on locks)
I see what you are saying, after doing a zwave radio reset the entries are not in the zwave list anymore. When you try to remove it from the hubitat Devices list though it is still trying to "exclude" the device that no longer exists? Is that correct? Then you have to wait for that to time out to "force" remove the device from the devices list?
Another option would be to get a Hub Protect subscription. It would allow the backup of the z-wave radio for restoration to an existing or new hub. Swap apps device also is good with the caveat it doesn't work on child devices.
Correct. Interestingly, about 1 out of 10 device removals skips the force remove process and quickly removes the DB entry. Its as if the internal zwave interface immediately returns success letting the hubitat software remove the device DB entry. Thats just my speculation. Would be great if it always worked that way!
@gopher.ny there are two issues going on here you may want to know about, or some other dev not sure who.
After adding a new device via zwave inclusion, the Edit button for the DNI appears to be unavailable until after rebooting. Is this intended?
When trying to remove a device from the hubs devices list and the associated device was already removed from the zwave table (by a radio reset or otherwise I presume). In this case the hub is still wanting the user to exclude the zwave device. Not sure if this is expected behavior?
New info. I tried something different prior to the Remove device step. Right before removing I edit the DNI to something in valid range but never used (ie 99). The removal works as I would expect without any delay and no extra Force Remove step.
I've done this with a dozen devices (setting to 99) and every remove works quickly and as I would hope.
So if the UI would detect when the DNI is out of range (greater that 256, eg B1C) maybe it could take a similar path and just remove the DB entry.
I don't honestly remember when, but reasonable guesses are when the Z-Wave Details table has no matching node ID (by hex, sans 
