It's always a good idea for applications to know what their current working directory is, or to make it immaterial.

In my case, I started out in the reverse scenario. I started with merely using the path where my executable lived as a base, and used File::Spec's catdir and catfile to build the absolute paths to any files I needed. Then I put most of those (at least the directories) into another module where I could then do Locations->config_dir() and Locations->data(). And then use those to build up even further. Why? Because when I log/trace the path to whatever I'm looking for, having an absolute path allows the human who is reading it to better figure out if it's right or not.

Then, somewhat mimicking what you're doing, I wrote a task hierarchy. For the same set of scripts. And the task manager object would actually save the current working directory before running each task, and reset it after the task, so that the task could do whatever it wanted, and I wouldn't worry about how adding a new task may make an old task stop working. At least by changing the cwd. Mostly, I only use this when building tarballs automatically. Since I no longer have to worry about the current directory (or resetting it), I don't need to write my fallback: fork, chdir, exec.

However, at no time should you need to worry about the current directory in END. Since the current directory is merely part of your process' environment, you will never affect the calling program's directory. Which is partly why I had a fallback for creating tarballs: fork a new child process, chdir in that child, leaving the parent unchanged, and then exec tar. Meanwhile, the parent would wait for the child, and not need to touch the directory. Yes, I know, I could just chdir back. But, for some reason, this way made me less likely to forget. Probably because it was so painful that I had to actually pay attention ;-)