Like the man said, there had to be a reason:) I would dispute that it is a good one though. Apart from the lack of intuativity (Is that a word?), there are just so many ways to break this.

The heuristic can be summed up as:

• I want this piece of code in my main program to be the very last thing executed, so where do I put it?
• Well, before anything that you want to execute before it.
• So, I put it at the top of the program?
• Well, no. If you do that then it will be executed after the END blocks in any packages you use which might not be what you want, so put it at the top of the program, except after any use statements for packages that might have END blocks that need to execute after your END block.
• But how do I know if the modules I use need to execute their END blocks after I execute mine?
• Read the source Luke. And hope that the authors thought to document the need.
• Come to think of it, why might they need to do that?
• Well, the module might class data shared by all its instances that need to be cleaned up. This cannot be done as a part of any individual instances DESTROY method, so it has to be done in a END block.
• Ah! But that goves me a problem. My program is converting some irreplaceable flat-file legacy data to DB format. I want to ensure that the file gets deleted after it has been successfully input, and that is what I am going to do in my END block, but I need to ensure that the data has been succesfully flushed to teh DB first. If there is any chance that the connection will fail and the data I stored is lost or corrupted, then I don't want to delete the file. How do I handle this?
• You've got backups of the files haven't you:)

A bit contrived but, it still seems more than slightly weird to me. Sort of makes me hanker for the simplicity of old-time basic's line numbered code:)