I reviewed your logs and have some comments:
1. I can see the problems you first hit at ~23:35, which causes the secondaries to crash. Also, as the replica set members come back up, we try to catch up but hit the same problematic transaction again.
2. I don't see the write actually going through in your logs. I wouldn't expect the write to go through on the secondaries while the unique index exists.
3. I can see the index being rebuilt around 01:40 on d3 (which is the primary at this stage?). Not sure what this was for. I see more errors (for the same duplicate key) as late as 08:44 on member d2
4. Since there are only logs from the incident (but not earlier), I can't ascertain how the index inconsistency among replica set members happened in the first place.
4a. Certainly there is no requirement for indexes to be the same across replica set members (i.e. you may want one member with an index for a certain batch reporting job that runs, but on no other members).
As you have moved past this issue and probably no longer have any of the data from the incident, there is not much else we can advise without resorting to pure guesswork. I will resolve this ticket; however if you have any further information related to this issue, please feel free to re-open with additional details.
Thanks and kind regards,