As I mainly do internal tools, the reactive bugfix approach has always been fine. Though I’d say the same for even production tools – this article is about reporting leaks, which is a debug feature, so we’d not want it to compile in release builds anyway. I’d just wrap the GC calls in #if DEBUG and call it good.

But all of the above is irrelevant. The fact is, the documentation says WaitForPendingFinalizers is not guaranteed to exit, so we can’t rely on it to exit. Lets say some Windows Update or more likely a new .NET version comes along and changes the behavior a little bit but still abides by the documentated behaviors… just look at how many people changes like the .NET 1.1 to .NET 2.0 changes broke because they were relying on undocumented behaviors of GC.Collect and WaitForPendingFinalizers. Relying on undocumented behaviors (even “good” ones such as situations where it _didn’t_ used to block) means that such updates are free to break our code w/out apologies.

That said, the simplicity of the two-line approach you use is certainly worth taking a reactive bugfix approach to, so long as the tool is internal or whatnot. I wouldn’t have implemented the Thread approach if I hadn’t seen the problem firsthand.

I suppose if I did see it a few times I’d do the start/join/abort you mention, and have the code file a minidump with the bugbase before the abort as a high severity issue.

At this point, it may make sense to house this functionality so it can be called with one line of code from, say, a static method like:
static void SafeDisposer.ValidateDisposals(timeout) {…}