Of particular note are:

jstests/noPassthrough/index_builds/index_abort_stepdown_prepare.js
jstests/noPassthrough/index_builds/index_build_stepdown_prepared_transaction_intent_shared.js
jstests/noPassthrough/index_builds/index_stepdown_prepare_conflict.js
jstests/noPassthrough/index_builds/index_stepdown_during_scan.js

These tests become racy in the primary driven suite (sometimes the index commits and sometimes not). We should evaluate whether this non-deterministic behavior is a correctness issue or a test interaction with primary driven index builds.

Also, it may be worth investigating whether these tests even probe the advertised deadlock in a primary driven index build scenario. If not, we may want to keep them disabled.

There are also a host of tests such as:

jstests/noPassthrough/index_builds/index_failover_resolved_key_errors.js
jstests/noPassthrough/index_builds/index_stepdown_abort_prepare_conflict.js

Whose descriptions outline scenarios that may simply not apply to primary driven index builds. These tests might also pass (effectively becoming no-ops) when primary driven index builds get closer to feature parity with simultaneous.