S11/"Runtime Importation" talks about allowing both module names and file names, but it does not specify how the compiler (or rather the runtime) should figure out whether a given variable should be taken as a module name (to be looked up in @*INC) or as a file name.
Perl 5's approach of always assuming a file name if it's not a bare package name is too limiting IMHO, it leads to needless (and buggy) reimplementations of module locating code.
My best idea so far is to create a second keyword, 'require-file', which always interprets its first argument as a file name.
An idea I like less, but which might work for many cases, is to treat the presence of a dot in the string as an indicator that it's a file/path, not a module name.
Better ideas are welcome too.
That sounds pretty dangerous -- a 'touch YourModule` in the current working directory could make a working program stop work. And execute code not in @*INC, even though that's not what the programmer meant.
Seems that I accidentally edited my comment. The idea was to check for existence of the file and decide basing on that. I agree that it's probably unsafe though.
I vote for require-file since if I do require Something and mean a file, and later there is a module called Something I get problems...
Maybe have a flag for require, like :file or :path? Or, how jnthn++ suggests, just make decision basing on the type, so one can do require 'foo'.IO or so
semantic clarifications of new require forms