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