Defining what Aperture regards as a 'new' file.

Question

If I import referenced file from a directory, then something changes the mtime of that file, Aperture regards it as a 'new' file and I end up with what appears to be two masters identical in appearence with the same file name.
The behaviour I expected was that a new file was just that -- a file that hadn't been there before.
I've done this by mistake twice -- and now once deliberately.
This is a problem.  If metadata has already been written, then each file must be checked to see if it is the one with metadata in order to eliminate the correct duplicate.
(I'm scanning images for an alumnni school llibrary.  I have 20 milk crates of albums to do.  I typically will scan while watching the tube in the evening, then apply metadata later in the evening. Each binder is a 'project'
I can the following ways to work with this:
1.  Don't even think about applying any metadata until a project is complete.
This way, any time I import twice, I can just chuck that whole project and re-import.
2.  Carefully track the last file name entred, and make sure that I don't have any thing aready in the library checked for import.  This is tedious.
3.  Create new folders as needed so that no folder is ever used twice for import.
4.  As I add metadata, also give pix a rating. In eliminating duplicates, I just do ones that are not rated.
Is there a better answer?
Is there a way I can tell aperture "don't import duplicates" means don't import a file if there is a file of that name?
If you want to reproduce this error:
Import a folder of files.
Open a terminal window, and navigate to that folder.
Run the command "touch *"
Now all the files will show up if you import from that folder AND have Don't import duplicates checked.

Answer 1

I'm not sure just what I'd done the accidental times.  I think it was using photosweeper, a duplicate and similar pic finder. (Recommended, BTW)
However I end up with TWO images in the browser that act like separate masters that both refer to the same external referenced file.  Not clear what happens if I delete a version and master.  I'll try that in my test folder.
As to the other problem.  I used referenced files, because I use programs other than Aperture.  Which is one of the reasons it's easy to shoot myself in the foot, I'll admit.
As an example:
Import a set of files from a folder.
Chuck the duds.
Use external program to write NAD27 location data to geotag.
Reprocess masters to pull the geotag data.
Now that I'm aware of the problem, I'll just delete versions and re-import, and NOT assign metadata while a project is in flux. 
(As an example of a project that is in flux -- I own a tree farm.   Over the course of a year, I take several thousand pictures for inventory.  With this bug, I'll make sure that each day's shoot comes in as a separate project initially, and then after I've done with it, I'll move those pictures into the long term project.  Probably a better work flow anyway)
As to the two cameras issue.  I don't have two Nikons, but I ran into that problem when I was teaching photography.  Most cameras allow you to change the prefix.  I had my students change it from IMG to their initials. 
In your camera case, to me it is unlikely that you would have both cameras iimporting into the same folder with the same number.  Still, this is a reasonable border case.  My requirements for unique file name would be within the same folder.  With internal files, Aperture renames them according to date and time I think. 
For referenced files imported from a folder a pre-existing name should be reprocessed, with metadata merged.  That would be my usual reaction.  But there should be choices.
Consider:  If I moved the file there, I've ALREADY clobbered the old master.  It doesn't exist anymore. Aperture should detect this and do the right thing.
More signficantly, if Aperture wrote INTO the file something like "Aperture imported on {hostname} Aperture ID 1122334455 or whatever string Aperture uses for a key for this image in it's internal database, then:
A:  Aperture recognizes that some other program as been messing about.
B:  Aperture knows that this file is already in it's database, but MIGHT have been modified. (And therefore should be flagged for the owner to check adjustments.)
Aperture could do some things that are more clever:  When it suspects changes in the file, I extracts a new preview.  The new preview is compared to the old one.  If Identical, then the image is the same.  If different but close, and in the same project, the user is alerted, and asked   Keep both?  Keep newer  Keep older Keep newer, and move metadata...  Remember choices for rest of this import. 
As a more extreme example:  My scanner creates TIFFs.  A 2000 x 3000 pixel image of a slide is about 45 MB.  As a png file (exact same data, but better compression) it's about 30 MB.  I'd like to import, sort, change to png.  Instead I change to png before import.  It's uses more cpu cycles since I'm processing files that will be discarded, but cpu cycles are cheap. 
Part 2 of this answer:
Because I keep referenced files and because Aperture doesn't track derivative files, I try to give my photos meaningful names, so that from the name of a file much of it's pedigree is apparent. If Aperture tracked masters by an internal tag, then derivative files would be a LOT easier to track.  Aperture could then go with the flow if I used a perl script to rename files. 
So, for example, I've done many canoe trips.  The first one was on the Fond du Lac river in northern Saskathewan.  So they are renamed FDL-001  FDL-002.  Now that I'm no longer limited by dos nameing conventions (or writing them in tiny print on the edge of a slide) I'm more likely to name them Fond_du_Lac-75-001