We could extend the recipe json format to allow conditionally skipping the loading of some recipes.

Example use case: loading certus quartz crystal -> certus quartz dust grinding recipes when AE2 is loaded.

A possible extension could look like this:

// Standard MI recipe format
{
  "type": "modern_industrialization:macerator",
  "eu": 2,
  "duration": 200,
  "item_inputs": { "tag": "c:certus_quartz_crystals" },
  "item_outputs": { "item": "appliedenergistics2:certus_quartz_dust" },
// Additional conditions, the recipe will be skipped if the conditions fail.
  "fabric:conditions": { "mod": "appliedenergistics2" }
}

The challenge is picking the exact format, designing an API that allows defining custom conditions and providing a set of useful conditions (mod loaded, AND, OR, others?).

Hmmm yes I meant JsonElement. 😄

Is this still going to work when Mojang move to Codecs for the whole datapack? I guess operating before the parsing is ok.

If that happens we'd probably get rid of the API, or replace it with a codec equivalent.

How will this interact with what KubeJS (and other mods) do to the recipes?
https://github.com/KubeJS-Mods/KubeJS/blob/main/common/src/main/java/dev/latvian/kubejs/mixin/common/RecipeManagerMixin.java
Note the ci.cancel() at priority 1100 to stop the vanilla code reparsing them.

RebornCore has a similar system and it works with KubeJS. I think the priority of 1100 is to run after RC's handler, so if we use the default priority we should be fine. Will obviously test it in production (i.e. AOF4).

This is also needed for loot tables, which likewise fail if an item is not defined (so Adorn for example needs LibCD's conditional data for mod compat)

I think the conditions should all have to be valid for the recipe or loot table to loaded. If you want more complex logic then you can add your own condition in code to handle that.

Why not just allow a:

  "fabric_optional": true

that suppresses any error loading the data when it is present.

This doesn't need any complex logic (that could easily introduce other bugs)
and will pretty much automatically adapt to most use cases?

Errors are quite useful to find mistakes. That solution looks like a hack, especially given that conditions are quite easy to implement (essentially they are just Predicate<NbtCompound>) and they can be more powerful, for example we could allow per-input or per-loot pool conditions eventually, or at least some mods could use the API for their own recipe types.

Predicate<NbtCompound>

I think you mean JsonElement?

Next issues (since as usual you ignored my other ones :-)

• Is this still going to work when Mojang move to Codecs for the whole datapack? I guess operating before the parsing is ok.
• How will this interact with what KubeJS (and other mods) do to the recipes?
  https://github.com/KubeJS-Mods/KubeJS/blob/main/common/src/main/java/dev/latvian/kubejs/mixin/common/RecipeManagerMixin.java
  Note the ci.cancel() at priority 1100 to stop the vanilla code reparsing them.

Perhaps a "skipping recipe X because recipe conditions <json of the conditions here> are not satisfied." 
Well I don't want to have 100s of "failed to load recipe" errors just because some mod was missing.

You can probably put the failed ones in a HashSet/Map and print a summary?
JsonElement and its derivatives implement equals() and hashCode() like the java collection framework.
100 recipes not loaded because {"mod_loaded": "foobar"} is false

DEBUG log could be useful though. 

Good luck getting a player to enable debug if your recipes aren't appearing in their environment. :-)

Errors are quite useful to find mistakes.

I am not saying don't show the errors (warnings).
I am saying don't stop the data pack loading if optional data can't be loaded.
That's a pretty simple semantic and not really a hack.

Recognising a problem in conditions (either in the implementation of the framework or its usage by developers/players) will be much harder to track down. i.e. Defined conditions != actual usage.
You will at least need the same logging to "warn" a condition wasn't satisfied so people can debug them.

If you do implement conditions can you at least include a condition that has this semantic? :-)

I am not saying don't show the errors (warnings).

Well I don't want to have 100s of "failed to load recipe" errors just because some mod was missing. Perhaps a "skipping recipe X because recipe conditions <json of the conditions here> are not satisfied." DEBUG log could be useful though.

If you do implement conditions can you at least include a condition that has this semantic? :-)

My idea is that conditions would essentially be Predicate<NbtCompound>, to make them pluggable into almost any kind of json format. So conditions can't really implement this behavior themselves.