Question. Have you, in any real code that you have written (as opposed to hypothetical code that you might choose to write some day) ever been bitten by this behaviour? Have you seen anyone complaining about problems which they had because of it?

Me neither. And it has managed to do the right thing when I needed it in some relatively complex cases.

As for your module loading question, that is a red herring. Why should it matter what order you use the modules in? If the modules have dependencies, they are responsible for pulling them in, and in so doing will guarantee that any functionality the module needs to have when it unloads will still be there. OK, so this system can get into trouble with circular dependencies (for instance Carp and Exporter have to play games because each depends on the other), but that is at load, not unload. It is not your responsibility to manage your modules' dependencies, and it turns out that you don't need to.

And now because I pointed out how to create a problem (with exec) you raise that case. Well it is valid, if you wish to use exec you can quickly cause a headache. Use exec in a complex C or C++ program and you cause similar ones for the same reason. (Using it within a Perl script is arguably just using it in a complex C program...) But it seems that most people who want to use exec manage to deal.

Now suppose that someone comes up with some reason why their module should have its END go last. I have never seen that module, but I can dream up cases where you would want to. Well were I writing that module, I would document that fact up front because it is an important usage note that people are going to have to work with.

Now suppose that someone else came up with another that did the same. And you wanted to use both. Um, well, good luck. Odds are that if they both want control of the end slot, they do things that are pretty incompatible. If you want both things to happen you probably need to make two system calls (or fork and then load each separately, or something else crazy). Perl cannot anticipate every possible need all of the time. And should not worry itself overly about anticipating needs that people can dream up, but nobody has apparently ever wanted in real life.

But if you really want to get more control over END blocks, odds are pretty good that you could go stare at Perl's source and find where the END blocks actually get stored for use in cleanup. You can write a module that can go and manipulate those internals to your heart's content. It would actually be useful if you used it to implement versions of exit and exec that actually call the END blocks before exiting.

However I don't think that you will find that anyone is particularly unhappy with how END blocks work in practice. (You might find some unhappiness with exit and exec though. But not that much since most people have found their own ways around that possible breakage.)

And finally, given that END blocks don't cause significant complaint now, and the person who was in charge then is still in charge, well guess what I predict Larry Wall is going to say in the appropriate Apocalypse?