Not sure if that's currently maintained, but the following mixin

https://github.com/Chocohead/OptiFabric/blob/llama/src/main/java/me/modmuss50/optifabric/compat/carpet/mixin/WorldRendererMixin.java#L19

seems to have troubles with

https://github.com/gnembon/fabric-carpet/blob/1.17/src/main/java/carpet/mixins/WorldRenderer_pausedShakeMixin.java

which it targets, I have that mixin as optional so maybe its not injecting because of optifine.

Not sure what to do with that. The following errors shows up:

Caused by: org.spongepowered.asm.mixin.injection.throwables.InjectionError: Critical injection failure: Variable modifier method doChangeTickPhase(F)F in optifabric.compat.carpet.mixins.json:WorldRendererMixin failed injection check, (0/1) succeeded. Scanned 1 target(s). Using refmap optifabric-refmap.json

Yeah OptiFine changed one of its patches to be slightly less invasive so OptiFabric's fix stopped being needed. Seems to all be happy without it.

wasn't that the other mixin that was failing? the WorldRendererMixin

Yeah, this should be detecting new chunks generated, and it isn't anymore with optifine on board:
/script run __on_chunk_generated(x,z) -> print(player(), ''+x+','+z)

I think this is a bug in the attempt to recycle older runs with the extra lambda mappings fixed in place. As it stands LambdaRebuilder only gets 4 of the 14 lambdas in ThreadedAnvilChunkStorage, but conveniently the one you need is one of the four:

Partially matched 4/14 lambdas
	net/minecraft/class_3898#lambda$null$19(Lnet/minecraft/class_1923;Lnet/minecraft/class_3193$class_3724;)Ljava/util/concurrent/CompletableFuture; => method_20440(Lnet/minecraft/class_1923;Lnet/minecraft/class_3193$class_3724;)Ljava/util/concurrent/CompletableFuture;
	net/minecraft/class_3898#lambda$null$17(Lnet/minecraft/class_3193;Lnet/minecraft/class_2791;)Ljava/util/concurrent/CompletableFuture; => method_19534(Lnet/minecraft/class_3193;Lnet/minecraft/class_2791;)Ljava/util/concurrent/CompletableFuture;
	net/minecraft/class_3898#lambda$chunkGenerate$20(Lnet/minecraft/class_2806;Ljava/util/concurrent/Executor;Lnet/minecraft/class_3193;Lnet/minecraft/class_1923;Lcom/mojang/datafixers/util/Either;)Ljava/util/concurrent/CompletionStage; => method_17224(Lnet/minecraft/class_1923;Lnet/minecraft/class_3193;Lnet/minecraft/class_2806;Ljava/util/concurrent/Executor;Lcom/mojang/datafixers/util/Either;)Ljava/util/concurrent/CompletionStage;
	net/minecraft/class_3898#lambda$null$18(Lnet/minecraft/class_2806;Ljava/util/concurrent/Executor;Lnet/minecraft/class_3193;Lnet/minecraft/class_1923;Ljava/util/List;)Ljava/util/concurrent/CompletableFuture; => method_17225(Lnet/minecraft/class_1923;Lnet/minecraft/class_3193;Lnet/minecraft/class_2806;Ljava/util/concurrent/Executor;Ljava/util/List;)Ljava/util/concurrent/CompletableFuture;

Running without an .optifine/with a never before used OptiFine version with v1.11.9 I get the expected output, which makes sense as method_19534 is being correctly added back from lambda$null$17. But if an existing OptiFine version is used (existing in the sense that any OptiFabric version before v1.11.3 was used when it was added to .optifine) the output isn't there, lambda$null$17 is never being renamed. You can actually emulate this behaviour running with v1.11.9 with -Doptifabric.exactOnly=true, with that none of the 14 lambdas are renamed, although there is no purpose to use this other than to confirm the theory.

It poses a bit of a problem in that there's no way of knowing if a version was recycled or not, other than reapplying the lambda rebuilder again and seeing if anything extra is found. If this is an especially widespread problem I can do that, otherwise this will fix itself when people start a new OptiFine version, or delete their .optifine and run again.

Thanks for looking into it. As long as it will 'fix itself with time' I am perfectly fine with it. Thanks for addressing it :)