Here's a simple repro script, inspired by jstests/core/index_bounds_pipe.js:
Note this this only triggers the problem if you also include the changes for
SERVER-64315, since this repro depends on the caching of single solution plans.
I believe the problem is similar to SERVER-64776 – namely, the bounds tightness of the regex predicate is not correctly incorporated into the plan cache key. The first regex, /^a/, has exact bounds tightness, and therefore the predicate is "trimmed" and not included as an explicit filter in the execution plan. In contrast, /^a|b/ has inexact bounds and the regex must be reapplied to each index key. However, this query reuses a plan that has no filter stage. Consequently, the predicate does not get reapplied and the query returns extra results.