I had a similar issue to contend with using the GridFilters extension actually.
The datepicker assumes the keyNav exists an attempts to disable it again. The fix I came up with avoided the attempt to destroy the picker twice, but I'm wondering if that's the best way if other classes have similar problems.
If the keyNav.disable() had been wrapped with a check to see if keyNav existed I would never have found that I wasn't destroying it properly the first time though. So in that sense it was good not to just bandaid it by wrapping inside an if (keyNav) check.
Side note, discussion. Seems that wrapping things in a window is useful for inspecting cleanup. I've exposed problems of items not being cleaned up properly or at all wrapping something in a window and closing it.
The talk about keyNav.disable() being wrapped with a check is the "hurtful" defensive programming you can get yourself in trouble with! I've found that certain types of defensive programming is extremely bad because they hide errors like that. It's good that the code was just blindly trying to access null elements with no checks (in that case anyway) because it shouldn't be called twice anyway.
The whole wrapping thing in a window is a good thought. I just happened upon it but didn't realize it could be a good strategy as well.
What do you think the proper fix is for the row editor and the date picker?
I defer answering what the proper fix is at the moment.
I will add another comment though, bringing up an old request again, that it would be good if there were some template methods in place to destroy plugins as well. I mean there is a check to initPlugins if plugins exists, so I don't see why we wouldn't have some kind of template method to call upon destruction (beforeDestroy, destroy, onDestroy).