concurrentStoreAndDispatchQueues means that we dispatch messages while they are pending write to the message store.
The async writes are potentially out or order w.r.t sync writes - we use sync writes for transactions. If we reach out memory limits and need to sync with the store, then we need to deal with the ordering issue when we set up our first read from the store. The store may replay some messages that were stored async and the cursor will trap these messages as duplicates. However the audit is the component that does the trapping and that can be misconfigured. Also there will be some performance penalty when we revert to the store for the first time.
In short - when concurrentStoreAndDispatch is in use it is best to constrain the broker such that the cache does not get exhausted. Use pfc and cursorMemoryHighWaterMark=110 so that the dest limit is reached before the cursor gets full.