I slightly modified and re-ran Shay's query from T264193 for version 6.8, and these were the results. After the re-implementation of the storage model, we are now seeing slightly more events produced on the MEP side.

I am not sure how concerned we are about these very small discrepancies or what actions we intend to take as a result of this analysis. If I recall correctly, last time we (Jason and Toni and I) discussed the issue, we decided not to maintain the iOS-specific storage model in the iOS MEP client anyway.

WITH user_event_counts_legacy AS (
    SELECT
      event.app_install_id AS app_install_id, event.action AS action, COUNT(1) AS n_legacy_events
    FROM event.mobilewikiappiosedithistorycompare
    WHERE year = 2021
      AND useragent.os_family = 'iOS'
      AND useragent.wmf_app_version >= '6.8'
    GROUP BY event.app_install_id, event.action
), user_event_counts_modern AS (
  SELECT
    app_install_id, action, COUNT(1) AS n_modern_events
  FROM event.ios_edit_history_compare 
  WHERE year = 2021
    AND user_agent_map['os_family'] = 'iOS'
    AND user_agent_map['wmf_app_version'] >= '6.8'
  GROUP BY app_install_id, action
), user_event_counts_joined AS (
  SELECT
    app_install_id, action, n_legacy_events, n_modern_events
  FROM user_event_counts_legacy AS legacy
  JOIN user_event_counts_modern AS modern
  USING (app_install_id, action)
)
SELECT
  action,
  SUM(n_legacy_events) AS n_total_legacy_events,
  SUM(n_modern_events) AS n_total_modern_events,
  100 * (SUM(n_modern_events) - SUM(n_legacy_events)) / SUM(n_legacy_events) AS percent_difference
FROM user_event_counts_joined
GROUP BY action;

A number of the hypotheses I listed in T281001: [SPIKE] Investigate legacy vs. modern event submission inconsistencies for Android user contribution screen could also help to explain the loss of events on iOS prior to the reimplementation of the storage model:

1. Events are sent to the old system immediately but enqueued for a period of time with the new client library. A small number of enqueued events that were submitted to the old system may be lost before submission to the new system when the user quits the app.
2. It would not be unexpected for transient network or server errors to produce a small number of discrepancies on either side. (These should be approximately equally distributed between legacy vs. modern, assuming that the 5xx error rate for eventgate vs. the MediaWiki appservers is rougly equal).
3. Users may be using ad blocking software that blocks requests to either or both endpoints. This depends on the ad blocking configuration used and is entirely out of our control.

Context/Back-Story Regarding the iOS-specific storage model change:
iOS app was very interested in pushing offline use cases generally and as a matter of global equity. There are a number of reasons you may use offline so wanted to make sure we saved events.

iOS sticks events into table and then retries for 30 days to send them. Initially planned to do this for Android as well but decided not to do this.

We decided to not do this anymore because we wanted to preserve user battery and bandwidth by not trying to constantly be trying to send analytics. Also improves the overall quality of the events data we are storing locally.

Conclusion
Since we removed iOS-specific storage model we can logically expect there to be a reduction in the number of events. Given this we should update the QA process to indicate that we can expect event counts to differ https://docs.google.com/spreadsheets/d/1ZpUEbGntW0NECyPsUijFgDwRXbczIOiTFwsGyN9yzL8/edit#gid=0.

Additionally (Product Analytics) could check to see if this impacts the overall insights taken away from the data. Look at a higher volume dataset like (session ticks) to analyze.