I think I see what you're getting at but I believe it's a little more subtle than that. I think it's more like there's just one record player and one record... and you can only play the record once. If you play it a second time, then the player skips and jumps and makes a mess of it. Perhaps you may liken it to playing a dusty record (clearly one needs to be an old timer here... like what's a record player anyway?
)... the player gets through it okay the first time, but so much dust has accumulated that if you start over again it just becomes too much for the player to handle. So to parse the analogy, the record player is S3D and the record is the STL file. Where does the fault lie? Is it failure to dust off the record before playing it, or is it failing to blow the dust off the needle after each play? To my way of thinking there's more of an onus on the player than the record in that there's no practical way for someone making STLs to determine if 'multi-plays' will cause problems... the example I provided fails on the 2nd play... but what assurances do I have now that it won't fail or the 3rd or 4th or nth play? To my way of thinking there's some failure in S3D to re-initialize a variable somewhere that's causing the problem and should be corrected. I would agree with you if we were talking about two STL files, one with a single object, and the other with two copies of it, but this is a single STL file with a single object and I think its reasonable to expect a slicer that provides for copy and pasting multiple instances of the exact same object that it should in turn slice any occurrence of it correctly.