Hey, DirTNT dev here!
I've written an internal texture stitching library named stitch to dynamically generate / add textures based of other textures, so I can generate TNT textures for potentially every possible block in the game.

Afaik older Continuity versions run fine with DirTNT/stitch, but compatibility broke with the 3.0.0 beta, see Fourmisain/DirTNT#5.
Here's the relevant excerpt:

java.lang.ClassCastException: class io.github.fourmisain.stitch.impl.StitchImpl$SpritesStage cannot be cast to class net.minecraft.class_7766$class_7767 (io.github.fourmisain.stitch.impl.StitchImpl$SpritesStage and net.minecraft.class_7766$class_7767 are in unnamed module of loader net.fabricmc.loader.impl.launch.knot.KnotClassLoader @5cb9f472)
at net.minecraft.class_7766.mdb6f098$continuity$lambda$continuity$modifyFunction$4$7(class_7766.java:1090) ~[client-intermediary.jar:?]
... 9 more

It looks like one of your mixins expects class_7766$class_7767 aka SpriteLoader$StitchResult, but instead gets my custom SpritesStage.

Due to the way the texture stitching stages are threaded, it wasn't easy finding a way to transfer data from one stage to another and to extend the stitching process without potential deadlocks or using a separate thread pool. The "best" solution I could come up with was to use a horrible @Overwrite to add 2 new stages to the stitching process.
prepareGenerating() is what returns our lovely SpritesStage.

I'm not actually sure how your mixin catches that, since the quoted code should be all SpritesStage is used for.
I assume you might have an injector targeting some lambda/s inside load?
Maybe they could target the internally called methods like loadAll / stitch instead?
Or maybe a solution could be as easy as adding an instanceof SpriteLoader$StitchResult check?
I'd try to look into it myself, but this repo's source code only goes up to the last 1.19.2 version.
Can you push your beta code to a separate branch maybe?

Thanks and sorry for the wall of text... 😅

I finally found a solution, and an extremely simple one at that.

The issue was that Continuity targets I think a thenCompose, which stitch adds a second of, and because the mixin had no index = 0 or similar, it targeted both of them.

For the fix I simply wrapped the additional methods calls in an external function, et voilà, no crash and working textures on both sides!