You can create preconditions to check for this sort of thing, but that ends up impacting the addition of source files for EVERYONE.  if the process is shared, you are then imposing this restriction on even those projects that do not require it.

I would do one of two things to address this situation:
1) Establish something in my build process that detects these conditions, and then FAILS the build, with an appropriate error message that allows the developer to easily determine which files overlap.
2) If all of the source needs to be in the same directory, then put it all into the same directory in the SCM system.

I understand that option 2 may have some performance impact as well, and may make working with the source difficult to do (as you scroll through the 20,000 filenames looking for the file that you want).  If this is the case, where there are a large number of files to deal with, then option 1 becomes my preferred approach.

From a philosophy perspective, I prefer option 1 anyhow.  If the build process is imposing this restriction, then it should be the build process that detects this condition and has to handle it.  I always cringe whenever we need to make tools (either IBM tools or someone else's tools) conform to bizarre standards or restrictions, due to the the inadequacies or idiosyncrasies of other tools in the development toolchain.  In short, "If tool A is broken, then fix tool A, and don't impact the performance and stability of tool B in order to address these deficiencies".