So far, submissions consisting of multiple files have simply been counted by summing up the scores of the individual files. Also file names aren't counted as long as they are arbitrary. (We do count file names if the code depends on them to work correctly, i.e. if actual code is outsourced to the file name.)
I've been making (ab?)use of that in Retina by determining the mode of operation implicitly from the number of files supplied. I don't see this particular case as much of a loophole abuse (but rather as elegant golfing language design), but there definitely is room for abuse:
- One could write a Unary derivative that doesn't take a string of 0s, but instead whose program consists of N empty files, where the number of files is interpreted as the unary code. This would essentially give you score 0 for arbitrary programs.
- One could use two different files with arbitrary contents and encode a program in binary from the sequence they are given to the interpreter (the first being 1, the second 0, or vice versa).
- One could identify the most common character in a language, and split the code into files around that character (i.e. the interpreter joins the files together with that character).
Before I'm further accused (winky face) of abusing loopholes, let's settle this and decide how we deal with multi-file programs when counting code golf.