Thanks so much, Abidos. This is going to be helpful when creating the script for 2.5/6. It makes it clearer why this isn’t as easily coded as I had expected. You can’t just copy an object, you have to know the data type and then link it.
In terms of the specification, you got it. Basically I think Blender needs a completely ‘neutral’, multi-copy command. By neutral I mean that nothing other than duplication is done, the position isn’t changed. So I’m not sure I like the idea of a positional offset. It should be left to the user to move the copies. Otherwise you’re really getting back to the kind of scenarios where the other methods would do better, DupliVert/Face, particles, etc. Just think of it this way: in what sort of usage would anyone specifically want copies offset by 1? Rarely, I think. On the other hand, 0 offset from original leaves you in a state that’s unambiguous and a good starting point for moving them.
Likewise with the question of linked or unlinked copies. They should be linked because that’s what makes them instances (the equivalent of Alt-D). It’s trivial to unlink them if required. Having the copies together under an empty would help (Shift-G to select all copies, then unlink).
That would be version 1. Version 2 could make linked/unlinked optional and I’m sure others could think of more bells and whistles.
I’ll keep an eye on the Scripting forum to see if anyone takes this up. If not, hopefully in not too long I’ll be able to have a go. I suffer from amnesia in Blender. If I don’t use a feature for a while, I forget about it. I haven’t scripted for over a month, and it would take me a day to get back up to speed, time I don’t have at the moment.