Ingredient is final, and thus extending it to cover NBTs is impossible without lots of hackery.

Proposal: As it is non-trivial to get right, Fabric should implement it by providing a public abstract class CustomIngredient that can be used to create an Ingredient, + serialization logic with types.

Questions:

• Should it be extended as such, or should mods simply lie/simplify for recipe previews and provide custom matching/crafting logic?
• Is there anything else to keep in mind?

You might want to mixin into RecipeFinder and/or InputSlotFiller so that the recipe book can fill custom crafts

A serverside version of Ingredient.ofStacks would be useful as well.

I also have a mixin to add an item stack aware version of getRecipeRemainder. See https://github.com/modmuss50/Retro-Exchange/blob/fabric/src/main/java/me/modmuss50/retroexchange/ExtendedRecipeRemainder.java

I think both of these could be good additions.

I wonder if the Ingredient hook should go into fabric-object-builders or into fabric-recipes. I think fabric-object-builders for a thin "ofStacks" exposure, and fabric-recipes for something more complex with custom ingredient type definitions.

Looking at the code, though, it's very much non-trivial to expose StackEntry. Humm...

The reason ofStacks is client-side only is becuase any data which isn't "item" or "tag" is not synchronized server->client. It makes sense, but the method ought to be called differently, then.

This seems to go hand in hand with #50, they could likely be combined into one module. Additionally, we have access wideners now so the issue of Ingredient being final may not be that big of an issue anymore.