Description
This is something I noticed looking through your code while working on a pull request that coincidentally fixes this very issue (see #143).
The serializer for cutting recipes applies a special case check to allow the type key in the tool ingredient to define tool types. Apparently forge already uses the same type key to allow custom ingredients serializers to be used.

Steps to reproduce:
Create a datapack which adds a cutting board recipe with uses a non-vanilla ingredient serializer for the tool ingredient, for example:

"tool": {
  "type": "forge:nbt",
  "item": "minecraft:stick",
  "count": 2
}

The recipe fails to load, because the recipe serializer tries to get/create a tool type called forge:nbt, which is not a valid tool type name.

Mod list:
Farmer's Delight 0.3.1-1.16.3+

Good catch. As stated on your PR, I'll wait before merging this fix, just to decide whether it warrants a 0.4.0 (since it's technically a breaking change), and whether to release the current minor updates as a dot release.

Is this why you can't have more than one cutting board recipe with the same ingredient, even if the recipe uses different tools? (This is a bug I've just encountered that may or may not be related to this issue. If you have more than one recipe with the same ingredient, one of the recipes cease to function.)

That could be related, but I suspect it may be due to the naming schemes.

I assume you suffixed your alternate recipe? (example: porkchop (knife) and porkchop_with_axe (axe)) If even then they cancel out, it could be some mistake in parsing that I have to look into.

Turns out this is actually a bug (unrelated to this issue) with how farmer's delight processes cutting recipes, so you're probably not doing anything wrong.
I've created a PR that fixes the issue (#161)

I suppose I'm not sure what you mean by "suffixed". Do you mean a different recipe name? If so, then yes, I have a different recipe name.

Woops, I merged the PR and forgot to close this issue. My bad. Thanks for the fix!