I'm making a modpack and I'm using Cyanide to debug issues with my pack. However, many mods haven't caught on to the fact that minecraft:music:jungle_and_forest has been deprecated, and I have to scour through every single mod finding which ones use it (i can't easily tell at glance from the namespace because the modifications are applied to the vanilla biomes) and patch their JARs (disabling them would cause conflicts with what i'm testing), just so I can debug a completely unrelated issue. Vanilla Minecraft doesn't care about this - it treats the slot as null and moves on. Cyanide catches this, and treats it as an error - perfectly fine in a single-datapack vanilla environment, where only the datapack dev is responsible for it, but in a large scale modpack with mods made by many developers it's unreasonable to treat warnings as errors. Adding an option to treat warnings as just warnings would help alleviate this issue; the game would still print the warnings and crash on serious errors, but it wouldn't crash on the warnings much like vanilla.

Given Mojang/DataFixerUpper@e491561, it's highly likely that in the next MC version (or the next version which bumps DFU, the behavior which Cyanide is modifying here is going to become required, across every optional field. Not just the specific ones that Cyanide replaces.

This isn't a correct characterization. minecraft:jungle_and_forest hasn't been deprecated, it has been removed. It does not exist anymore, and any mod using it has a bug in their mod, as there is almost zero chance that they intended, by writing minecraft:jungle_and_forest, to mean "no music".

Likewise, these aren't warnings - they are errors, that DFU ignores because of terrible design (as evidenced by the fact that so many mods have flag out bugs in their mod, that wasn't caught).

That said, I can see the utility in having a "compliant with vanilla" mode for Cyanide in which it does not break from the vanilla spec (which allows "music": "this is a valid music! it's the same as writing nothing. terrible spec."). However it will not be the default because again, it's a bug in these mods, you should ideally be reporting it to these mods, they are bugs and should be fixed.

--

Note that there is no way to make these "warnings" without making them utterly terrible, this is either a "compliant with vanilla, which means no warning for present-but-invalid fields", or "errors on some present-but-invalid" fields (current behavior).

I think this might just be the difference between the perspective of somebody debugging a mod and somebody debugging a modpack. As a modpack creator there is only so much you can do about errors in mods, so a lenient approach to errors is ideal - when you have a few hundred different mods, all made by different, amateur developers, there's no way in hell they're all going to be working well together, and you certainly don't have the time to patch dozens of mods yourself. Some mods might be outright abandoned, others may take months between updates, and a lot of people probably just don't give a damn about making their code perfect. (To say nothing of all the MCreator spaghetti code out there.) So 'good enough' is... well, good enough. You have to pick your battles, and typically that's going to be addressing bizarre crashes and outright non-functionality as opposed to scouring json files for a faulty sound event.

The linked DFU commit was added to minecraft 1.21 - that makes probably 90% of the cases this issue would cover become illegal in minecraft as well as cyanide, hence closing this issue as no plan to do anything else on my side.