Mostly, this is an idea. I hope, this will allow to more simple cross mod-loader mod development for CC.

Sure, this can be painful, especially with something like #873, but still I guess, can be performed.

can be performed.

These words are doing a lot of work here. You're going to have to elaborate :p.

Personally, I don't have any experience with Farbic, but after reading a bunch of documentation about it, I understand that only thing, that I could suggest in this case it two-level of interfaces.

Like, first level is generic API, that bound only to minecraft and CC:T inself, and then second level of API, that provide access to platform specific parts and stored in platform specific repository.

For example, we store ITurtleAccess in general API repository, and IForgeTurtleAccess in this repository.

And in real code, platform specific things also will have lines with type casting.

I am not sure, is there is another way to solve platform incompatibilities (like fabric itself doesn't have any api for fluid or energy storage).

Thinking about this a bit more, I just don't think this is worth it. Aside from the obvious hoops you have to jump through in API design, there's a whole load of issues with mappings. Currently we publish an obfuscated MCP jar - instead you'd have to publish one using mojmap, and do some weird stuff to load that into Loom/Yarn or ForgeGradle/MCP.

I suppose you could somewhat unify the API across the two platforms so that there is one set of docs that covers both platforms in most cases.

API are (mostly) already unified, because CC:R is just a fork of CC:T, as I understand. For example, ITurtleAccess.

But without separate API package it will be complicated to move CC:T and MC related logic away from modloader logic