As pointed out by chromatic, error conditions are generally best handled by throwing exceptions, and not by returning codes and assuming that your calling code is going to always write the necessary wrapper to notice the error conditions.

As an example of the programmer errors that the latter approach lends itself to, look in your own code to your use of string evals without any sanity checks for whether $@ is being set. As a general rule string evals are to be avoided as long as you have any other sane (or saner) alternatives. That is not to say that they are bad, just that they are very undisciplined as control structures. Furthermore using manually synchronized naming schemes as a control pattern lends itself to its own problems. You can use a manually syncrhonized naming pattern to do the same things you can do with real anonymous data structures. But the latter is much faster, more efficient, and saner to work with.

So to answer your second question, this is not the kind of code that I would like to see in production. And the main thing that I would cite is that it is trying to be too clever while ignoring basic principles of sane coding. Make sure that you have checked error conditions and will get debuggable information if things go wrong. Use real data structures where appropriate. If there exists a language feature (eg die/eval pairs) to do what you want, use it.

Sorry.