(this is all about 1.16-rc1, I'm only using optifabric as another example because it has less mixins than the replaymod)

Mixin has this "feature" (by not I'm not even sure if it's supposed to be a feature but it certainly acts like one) which, during certain methods of your IMixinConfigPlugin, allows you to queue additional mixin configs.

The ReplayMod uses this to ensure its mixins are loaded after Optifabric has setup Optifine: ReplayMod/ReplayMod@e3f621b#diff-c5c9e2e67532ff0b7e0fc8d6191e5d96

Optifabric does something similar for some of its mixin configs (and I'd assume will do so in 1.16 as well): https://github.com/modmuss50/OptiFabric/blob/597daea168e65eaefe95fddc51659c0e643d1281/src/main/java/me/modmuss50/optifabric/mod/OptifabricSetup.java#L50-L56

This is what it looks like with just Optifabric:

[20:41:49] [main/INFO]: Preparing mixins for MixinEnvironment[DEFAULT]
[20:41:49] [main/INFO]: Selecting config mixins.mm.json
[20:41:49] [main/INFO]: Selecting config optifabric.mixins.json
[20:41:49] [main/INFO]: Preparing mixins.mm.json (0)
[20:41:49] [main/INFO]: Preparing optifabric.mixins.json (1)
Found existing patched optifine jar, using that
[20:41:49] [main/INFO]: Prepared 1 mixins in 0.302 sec (302.0ms avg) (0ms load, 0ms transform, 0ms plugin)
[20:41:49] [main/INFO]: Checking for additional mixins for MixinEnvironment[DEFAULT]
[20:41:49] [main/INFO]: Selecting config optifabric.optifine.mixins.json
[20:41:49] [main/INFO]: Preparing optifabric.optifine.mixins.json (2)

However, this "feature" apparently does not work when carpet is installed. It'll just stop after the Prepared x mixins line and never run Checking for additional mixins for MixinEnvironment[DEFAULT].

Quite a bit of digging in Mixin's source later, I've discovered the reason: This "feature" will only work if there are no mixins for the first class that gets loaded in the DEFAULT environment (i.e. net.minecraft.client.main.Main). And carpet has one such mixin.

Afaict there's no other way to chain-load mixin configs, so the easiest way to work around this issue would be for carpet to not mixin directly into Main but instead into some method called by it (e.g. the referenced CrashReport;initCrashReport()).
It should probably also be fixed in Mixin but I'd rather not wait for that to happen cause that tends to take some time.

Boi - magic again.
I am not bound to Main - just when mojang started to shuffle their entry points, these were the best place to hook up for the init. I can look what best would be to hook it up into. Guess only have a few days for it.

Mixin into Crash Report has this obvious benefits, that reduces required mixins to 1 for the init.