Another option could be to implement retry directly in MsSQLReadStore, but we will lose ability to use RetryPolicies (or will really-really complicate MsSQLReadStore)

If you have a 1-to-1 relationship between your read model and your aggregate, you could try the AggregateReadStoreManager which checks if the version is as expected, applies any missing events and the updates the read model.

Thanks, that's interesting. It's +1 to this implementation (not retrying inside MsSQLReadStore).
However for that to work we need read store to signal that concrete Sql exception is probably OptimisticConcurrencyException, because various generic ReadStoreManager do not know that concrete code of SqlException XXX could be retried specifically in case of INSERT.
So, for me that change is net win.
If you have time, could you please reword your comment to be more actionable (leotsarev, please investigate this or that, try another approach, also add fix here or there, request review from somebody, add tests...)

@frankebersoll is this still relevant after you merged #768?

I think it's still relevant.
Before change + SingleAggregateReadStoreManager
If two threads (A & B) will try to create read model in parallel, one of them could fail and lose change.
Before change + AggregateReadStoreManager
If two threads (A&B) will try to create read model in parallel, one of them could fail and lose change (say, B).
Sometimes later when another update (C) to this aggregate happen, update B will be added to readmodel in correct order
After change
If two threads (A & B) will try to create read model in parallel, one of them could fail and signal OptimisticConcurrencyException. It will be retried.

@rasmus ?

Still relevant, haven't had the time to give it a go yet though