Describe the the feature you'd like
Crafttweaker integration should allow null inputs/outputs everywhere the base code allows null inputs/outputs.

For example: the base code of the PRC allows null item outputs, as shown by the default wood to hydrogen recipes. However, it is not possible to add additional such recipes via Crafttweaker as the PRC Crafttweaker methods don't allow null as output.

Legalizing null inputs/outputs in general would be nice, but that seems like it would take a lot of work for little benefit. So, failing that, it would be nice to legalize nulls in Crafttweaker integration methods wherever they're already legal in the connected Java methods.

Describe alternatives you've considered
Modular Machinery provides integration with Mekanism gases, and can therefore be used to create machines with arbitrary input and output types. However, while I am using it in my pack at the moment, it's less than ideal as MM machines are gigantic, kludgy, totally silent (sounds are one of Mek's biggest selling points IMO), and don't match Mekanism's general design.

This should be possible for PRC in 9.8.3.390

I think part of the reason the CrT methods don't have them be legal is I had not even realized at the time it was valid for them to be null (as at the time there was no recipes with output being null). I am going to put this under the 9.8.2 milestone. I think @thiakil is currently rewriting the recipe system internals so afterwards we can evaluate more in general having things be null.

Ah. Thanks for letting me know!

Would the recipe system rewrite involve real IIngredient/oredict support or is it planned to be less drastic so as to avoid breaking stuff? Or should I be asking Thiakil that question?

I ask because if Mek is going to support IIngredient, I figure I should fork and unbreak my CT scripts in advance.

Would the recipe system rewrite involve real IIngredient/oredict support

yup, that's 100% the idea

In java language, there's a big difference between null and empty itemstacks. Does such a difference exist in CT? (or is that a limitation of Mek's CT integration?)

null is the way CrT represents an empty item stack. At least that is how it works for Crafting table recipes. Not sure if null gets auto converted to empty for all ItemStack objects from CrT or not.

Also I don't think the recipe changes should break the CrT integration. It will just mean that adding recipes will be able to be cleaner.

A lot of my inputs are explicitly declared as IItemStack[IItemStack] maps before they're passed to any of Mekanism's methods. I assumed I would need to fix my scripts by declaring vars as IItemStack[IIngredient] instead.

It's a change I would make even if it's not strictly necessary, because I like to be able to see what's going on in my code, so "declared type is not real type" would qualify as "broken" for me even if it somehow worked.

If you look at nulls in general after the recipe rewrite, null gas and liquid ins/outs would also be nice. I don't need any of those in my current pack; I'm just thinking that would make sense from a consistency standpoint.

As far as I understand craft tweaker, an item stack definition would be a valid ingredient post switch-over (that just matches one item)

Iirc at the moment if you give mek ct an ore dict ingredient it just explodes (resolves) it internally

Fluids and gasses are getting the same kind of treatment; they're getting their own ingredient types (ingredients are just predicates at their core)