Maybe. I already have something that lets me look in alternate @INC paths for modules under development. This one was intended to allow me to not have to worry about copying that full directory hierarchy (most of our modules hang in a 3 deep path). Instead I wanted to just copy files in the same working directory and have development test code specify the next highest version. I'd test like that, then copy the new version of the file to the "current" one when done, saving the old one under an old version (at least for a while) Anything other than the current version would be file named by using a version suffix. That would allow for a pretty unlimited versioning development path (I think) without requiring new include paths. I'm probably missing other pieces though -- I just set up that small bit of test code so far.

The current module (one with the normal file name) is thus acting as the master. If someone asks to use a version other than the one it is, it would go out and try to substitute that version. That's where I'd like to stop compilation of the master file and switch over to the alternate version instead. All the unaliasing tests (useful in their own right) were the result of not being able to stop compilation of the master while continuing compilation of the alternate. Instead I let the master complete, I unalias all its imports, then compile the alternate version. As mentioned, this won't handle changes to BEGIN, END, CHECK style blocks across versions.

Maybe hanging this off the call to the VERSION method has led me down the wrong path here though.

More ideas welcome ...