If you're complaining about always having to go back to the man pages for the standard modules that you use every other week because you can't memorize them (as opposed to the things you use every day, and are therefor memorized), my vote is: get over it, get used to it, and do whatever works for you.

Before I learned Perl, I lived and breathed C, but every time I had to use read() or fread(), write() or fwrite(), or any of the str* functions, I had to go back to the man page, because I couldn't keep them straight. These days, I'm still going back to "perldoc perlre" more often than I'd like, in order to get the right syntax for positive/negative look-ahead/behind.

As for the "vagueness" of the term "path", it makes perfect sense in a unix/linux world, where directories are just a type of file, and a path is just a way to get to a file (whatever type it may be). As ikegami points out above, a path can be relative (to one's current position in the file system) or absolute. It can also be fairly twisty, with one or more "../" components scattered within it.

I have no problem with using more careful/specific terminology in appropriate settings, as demonstrated in your config examples, but I also have no problem with the current use of "path", even in the modules you mentioned as problematic for you. The ambiguity of "path" is actually functional.