My explanation of Taxon_occurrence_key constructions
Recorder import uses the following construction:

giving us a key

in fact, without the "nn" part what we have is a key which is unique right down to the level of Sample and the "nn" now enumerates all the individual taxa within that Sample thus

Whereas the managing of datasets by a recording scheme as discussed above requires

Datasets from contributors to recording schemes do have this kind of format, not all of them, but many do have the requirement for sequential numbering of their collections and may also try to use Recorder in the same way as outlined above.

Go back several years to descriptions of the Globally Unique Identifier principle (which you'll find in Charles Copp's description of the data model and also in the Recorder Help files) and you'll find the following simple description:

Acting upon this, many of us adopted this principle and assigned an 8 character unique identifier to our own records in what the new Recorder 6 Help file terms a "source system" and have been doing so since the last century. It was such a good principle.
At the time that the MapMate GUIs were being deciphered so as to allow exchange with Recorder there was a promise that the facility to import using these 8 character unique identifiers would be implemented in the import system. Seven years of effort were put into ensuring that source systems all had 8 character unique identifiers. But disappointingly this never seemed to get implemented.
Until now, with R6.10 and Sally Rankin's notes on the "Import Wizard - data format" page on the new Recorder Help file (the one on the CD):

Now the opportunity arises to take full advantage of the effort I've put into studying and implementing the data model and I can import all my Edinburgh Museum records (identified EM000001 to EM000965), Oldham Museum (OM000001 to OM003561), North West Hoverfly Recording group (HR000001 to HR015671), Invertebrate Site Register (IS000001 to IS000651), personal records (FR000001 to FR019198) into my copy of Recorder 6.
Seemingly not. Somewhere along the line the documented Site ID:running identifier::8:8 has been changed to Site ID:Unique index:running identifier::8:2:6 - I missed the documentation for this substantial change in the data model principles - was it ever documented.
You can see what happens next:
Working from my most recent personal records I successfully import using just the 019198 part of my identifier but as soon as I try to import using the lower numbers I find that they are already occupied by records I've already imported using systems prior to this utility and they try to overwrite entirely different records.
You can easily check this for yourself. Find an existing taxon occurrence of the form ADS00000100nnnnnn, write a 1 line spreadsheet for import with a Site ID of ADS000001 and a Record ID of nnnnnn. You will find the new record will attempt to overwrite the old one (you can stop it at the last stage, fortunately)
So in answer to your questions:
1. No, I added a code that followed the Site ID:running identifier::8:8, as published - and have been doing so for years as this was how it was explained in the model.
2. Yes
3. Recorder isn't a curatorial system. One of the primary needs of collecting entomologists is for data labels. One reason for the non-take-up of Recorder is that it doesn't provide the facilities to print a 13mm by 10mm data label or cater for specimens which are without identifications. Clearly these are conceptually different applications (and a huge topic which I cannot go into here). Therefore many use Spreadsheets or Access for their curatorial systems to allow them to do these kind of things. Specifically I have on my data label "FR019198" whilst the Recorder Taxon_occurrence_key is "ADS00000100019198" - near enough to be of great help in rapidly (GoTo Key) locating a record from the specimen, invaluable in  relating specimen to record (notwithstanding the Specimen module) and essential in ensuring that updates in the curatorial system get updated in Recorder 6 when I revise identifications in the curatorial system - the point that Sally makes in the Help file.
Not a straightforward topic I agree, Charles, but the ramifications of the ?undocumented change in the data model are considerable. We need a fix for this one way or another.

Thanks, John. You've expanded on an element of my notes and that would have been all that I needed to know until I read Sally's notes on Importing in the new Recorder Help.
It does actually work as she says and refuses Record ID s of more than 6 digits. It is there so presumably it was written in to the Import routines at some point in time with the intention of tying in with sequential numbering in a "source system" and I have investigated it for the reasons stated above.
I've contacted her and asked for clarification.
Charles has spoken about the Luxembourg add-in, sounds very interesting.
About a tenner and in time for Christmas would be nice.

Thanks, Sally.
For those of you who are taking notes.
Turns out my interpretation of how Recorder now allocates the various parts of the Globally Unique Identifier wasn't correct in my posting of 2007-12-17 09:19:09. My third paragraph & table, to fit in with what Sally says above, should have read:

in fact, without the "nn" part, what we have is a key which is unique right down to the level of Taxon_occurrence and the "nn" now enumerates all the various Measurements within that Taxon_occurrence thus:

I'm now investigating solution 3. from my 2007-12-17 09:01:17 posting.
I wonder how JNCC are going to react to my request for a whole bunch of Site IDs - watch this space.