Sure they would. All files are ingested and named sequentially. All files moved to one destination, locked ones to both. Same filename - two locations.
Files:
DSC_1000.JPG (locked)
DSC_1001.JPG (unlocked)
DSC_1002.JPG (locked)
DSC_1003.JPG (unlocked)
Sequence is 0001, naming is event_{seqn}
Destination #1 is set to copy only locked photos.
Destination #2 is set to copy both locked and unlocked photos.
Two ways to process: sequential and parallel.
Sequential:
If all of the photos are processed and destination #1 only copies as quickly as destination #2 allows then there is no speed gain by skipping the unlocked photos for destination #1, but the naming will be consistent
Destination 1:
event_0001.JPG (was DSC_1000.JPG)
[event_0002.JPG omitted]
event_0003.JPG (was DSC_1002.JPG)
[event_0004.JPG omitted]
Destination 2:
event_0001.JPG (was DSC_1000.JPG)
event_0002.JPG (was DSC_1001.JPG)
event_0003.JPG (was DSC_1002.JPG)
event_0004.JPG (was DSC_1003.JPG)
Parallel:
If the two copies were to happen in parallel and each were to have its own copy of the sequence, destination #1 would have different filenames than destination #2 but would complete the operation in about half the time as destination #2.
Destination 1:
event_0001.JPG (was DSC_1000.JPG)
event_0002.JPG (was DSC_1002.JPG)
Destination 2:
event_0001.JPG (was DSC_1000.JPG)
event_0002.JPG (was DSC_1001.JPG)
event_0003.JPG (was DSC_1002.JPG)
event_0004.JPG (was DSC_1003.JPG)
[naming is inconsistent]
Given that you were pressed for time, I had expected that you would want the locked files to be processed as quickly as possible and all of the files would be processed separately. If you don't mind that destination #1 'pauses' while unlocked photos in between each locked photo(s) then the naming would be consistent.
I understand now that you're wanting to reduce tedium and not have ultimate performance of the client receiving the locked files as quickly as possible.
-Kirk