ShardingTest has several ways to pass options to it (see this guide for a few examples) and it's not clear from the API how they are threaded into the eventually spawned processes, often with different implications for how they are merged with conflicting options. E.g. some startup parameters end up given to the ReplSetTest constructor while others go to ReplSetTest#startSetAsync(), which affects if the parameters are respected when nodes are restarted and how any sub objects they contain, like setParameter, are merged or overwritten.

Ideally we can simplify how ShardingTest sets its options to avoid surprising behaviors.