Yes, calls 1 and 2 are to the same FOLIO record. They're made by background jobs that are unaware of each other. I had hoped that if a 500 (or some other non-success response) was returned, we could simply retry that call. That would allow us to get the updated ID and try the update again. But retrying those steps (5-7) has unexpected behavior in that the "successful" operation for A does not seem to actually be successful.

Calls 1 and 2 are to the same record?
If yes then it could be a problem because it returns some IDs from mod-source-record-storage that are used then for update. After the update, these IDs are changed to new ones in mod-source-record-storage. So, 1-2 get the same IDs, 3 makes an update (IDs changed), and 4 try to do an update with the same IDs.
So, I think that it may cause you problems.
If it doesn't help - then please create an issue for us with all the details and we will investigate it.

That sounds plausible to me that mod-source-record-storage is the source of the problem. The calls are:

1. A: GET /records-editor

2. B: GET /records-editor

3. A: PUT /records-editor, 202 response

4. B: PUT /records-editor, 500 response

5. B: after getting 500 in step 4, retries

6. B: GET /records-editor

7. B: Record retrieved has the MARC 856 added in step 4, and does NOT have the update from step 3. Also, record has updateStatus["recordState"]="ERROR"

8. B: PUT /records-editor, 202 response

, I don't think it's due to optimistic locking. As I see from Laura's message the constraint is from mod-source-record-storage that doesn't have OL.
To investigate it more, I want to understand the sequence of calls. 
, Is it GET, PUT, PUT, PUT... or is it GET, PUT, GET, PUT... ?

Hey - do you think describes the effects optimistic locking? IF so, is there a way to show better error messaging? OR do you think this might have more to do with setup of the module?