The problem

Multiple mods add the same items or blocks. Examples: tin ingot, salt, coal dust, silver ore, etc...
One of the major tasks of pack devs (if not the major) that want to provide a smooth experience to their players is to identify all those duplicates, pick one variant and eliminate all the others from the pack, a process called unification. Here is what needs to be done for tin unification in AOF:

1. Decide which tin will be kept, for example tin from Tech Reborn (TR).
2. Use KubeJS' replaceOutputs to make all recipes producing tin ingots, dusts, nuggets, blocks and ores, produce the variant from TR.
3. Disable tin ore from other mods (Industrial Revolution aka. IR and Modern Industrialization aka. MI).
4. Hide tin variants from those other mods in REI.
5. Sadly they still appear as recipe ingredients, so use KubeJS' replaceInputs to replace the tag input in the recipes by a techreborn:tin_x input.
6. Remove redundant recipes, e.g. dust to ingot smelting. Having the same recipe appear 3 times in REI is not great.
7. Repeat for every relevant material and part. For example, only MI adds gears so MI gears need to be used even if TR steel ingots are used.

Obviously this is rather fragile. Anytime a mod changes its crafting items, this leads to unification bugs that must be ironed out over multiple releases. And this requires a lot of time that not all pack devs have. It would be nice if anyone could throw a few mods together and have all of this be done automatically.

Can Fabric API do something about it?

I think the Fabric community should find a way for unification to happen automatically, whether through Fabric API or through Minecraft's existing logic. In the absence of a Fabric API for this, I think this would be doable using the existing registry and resource pack systems:

1. Every mod checks the registries before registering its items and blocks.

   if (!Registry.ITEM.getOrEmpty(new Identifier("c:tin_ingot")).isPresent()) Registry.register(Registry.ITEM, new Identifier("c:tin_ingot"), new Item(...));

2. Block states, models and textures are done by agreeing on a standard path and letting resource packs handle conflicts.
3. Redundant recipes are done by agreeing on a standard id and letting resource packs handle conflicts. For example c:tin/crafting/ingot_from_block.
4. World generation does not need to be unified I think, because it's less annoying and that requires fine-tuning anyway depending on the balance of the pack. All generated ores will be the same block anyway.

What do you think about that system? Is it good enough, or should Fabric API provide some API to make material unification easier?

In any case, I believe automatic unification for any set of mods by default would be amazing for the Fabric community.

PS: I am not sure if I explained this correctly or not, let me know if you would like a clarification.

I don't think so (or at least it's not worth the effort). Have a look for yourself, it's not that bad: https://gist.github.com/Technici4n/df063e6a08514601bb8777ed295c2b2f.

No need, a kubejs script can do the job very effectively without explicit support from other mods. Check how AOF4 does it for reference.

Any way we could make it simpler?

This is really a longer term issue that is easily pushed back by more important issues such as events.

I think it's very important for existing mods, hopefully for 1.17. If enough people share their ideas on this I am willing to work on the implementation myself. ;-)

If it's doable with the existing systems in a way that causes no problems, then don't add another redundant system.

Recipes might not be easy to standardize - in which case a module could remove redundant recipes.