Perfection as a goal is a nice idea that can point one in a specific direction. However, since "perfection" is an ever changing (evolving?) and moving target, one must admit that perfection can never be obtained...

When in doubt, check the d4mn source code!
================================================
And here are my terms...

I don't care if you use my source code. (Known as "Code.")

I don't care if I get any monetary compensation.

I do care to receive credit for Code provided. So, please keep my name in the comments for Code provided.

Code is provided without warranty "AS-IS" and I claim absolutely no warranty nor liability to the quality, security, and run-ability on any platform.

By using Code, you accept all risk inherit with Code regardless if Code has known and yet to be discovered bugs.

You are welcome to change and improve the Code to best meet your needs.

I don't care if you use the Code in a commercial or open-source project.

I think replacing all instances of me.hide() with me.close() in the code is the way to improve it (I haven't tried it). The default closeAction of a window is destroy. So, when you close() a window, the instance is destroyed.

I don't know either why hide is being used.

If I understand it right, then close() is just an alias for hide() or destroy(), depending on what closeAction is set to. In previous versions I always destroyed the Notifications, but in the last version I changed the behavior. The default closeAction of a window is 'destroy', but it can also be set to 'hide' if reusing the window is desirable. The latest changes I made make it possible to reuse a notification object the same way.

For example if you check out the latest demo (http://www.eirik.net/Ext/ux/window/Notification.html) there is a button that says "BR - reuse". This shows the reuse of the component and the dom. A nice side effect in the example is that this automatically restricts the number of notifications to only one.

And the script actually does not call hide() more than once. From inside the overridden destroy() function. The reason for this is to make sure the notification fades out with an animation not only when the script closes it after the delay (autoClose), but also when the close button in the top right hand corner is clicked. There might be a way of achieving this without touching the destroy() function, but I felt it made sense to always hide the notification with the animation before it is destroyed.

After the hide animation is finished a new call is made to destroy() and the second time around a call is made to me.callParent(arguments) inside destroy(). So I am under the impression that this means all other destruction that windows normally perform will take place. The dom certainly is destroyed and I figured that was mostly what the destroy() functions did in Ext (take down the related dom). If there is a memory leak caused by the overriding of the destroy() function, then maybe that is because something else, like a pointer or circualar reference, should also be destroyed before exiting the overridden destroy() function. But since hide() calls removeFromManager(), then I can't imagine where those pointers are.

When it comes to memory management I'm on thin ice. Both JS and Ext wise. So maybe somebody could help out with some more insight? Or simply tell me a procedure I could use to test/visualize the leak, providing me a way to debug it.

Is there a way to either reuse or prevent multiple notifications appearing (that are the same)?

Yes. In the demo there is a button called "BR - reuse" demonstrating exactly how to do this.

In short you store the pointer to the notification when you create it. This can be done in advance as long as you don't call the show() immediately. And then you only call update/show every time you want to notify something. If the notification is still visible when the next updtae/show is called then all that happens is an update of the notification's content.