So I was defining a Modular Machine based loosely around Thermal Expansion upgrade mechanics and thought to try out if i could fit more than one effect target into into its modifier definition.

You can't, which is a bit of a shame because Thermal Expansion machine upgrades usually modify both the power consumption/production per tick of a machine and the duration of its recipes in one step, keeping the total power generated/consumed during the recipe the exact same across all upgrade tiers. You can't do this with Modular Machinery, as the modifier definition for each Recipe Modifier can only accept one JSON Object containing the target output type, I/O type, operator constant and the second operand.

This breaks immersion if you are designing all machines around a specific mechanical theme from a mod like Thermal Expansion that maintains fuel/energy value per recipe across all upgrade levels.

So i'd like to submit the following suggestion: let us define more than one effect target per Recipe Modifier.

There might be a possible workaround, which would be defining another Recipe Modifier that comes into effect from the same subset of blocks but affects the other variable that the definer desires to affect, but this might cause unintended behavior (switching between upgrades randomly) and would cause UI clutter on the Blueprint UI.

The existing recommendation is to include an item needed for the recipe that isn't consumed, such as having a specific capacitor or other upgrade block indicator, to alter the recipe, and having that in the machine's inventory.

A valid and completely functional alternative, but please also consider the following:

• Thermal Expansion machines change their sprites depending upon their upgrade level. This is to show the player working on/with them the upgrade tier of the machine at a glance, which an item inserted into the Modular Machine functioning as an upgrade cannot represent as easily by virtue of the item not appearing on the outside of the machine to give a visual indicator of the machine's upgrade tier.
  To check the upgrade tier would then cost (admittedly not a whole lot of) time to access the item input hatch's inventory and perform comparisons. Given a choice between the two I would rather have the convenience of a quick glance at the machine's exterior to determine the upgrade level.

• Additionally, Thermal Expansion does the method you suggested in addition to the aforementioned maintaining total recipe energy across upgrade level, through its machine augmentation system, which involves inserting an augmentation item into a special section in the machine's GUI; the machine then gains access to a number of different features or additional recipes as long as that augmentation item is in the machine's GUI. This function is pretty easy to emulate in Modular Machinery as per your existing recommended method, but it would require several added/modified recipe JSONs to account for the augmentation items' presences in the machine, and the additional recipes they might add.

• Also a possibly valid question: If the ability to add upgrades in the way you mentioned is the recommendation, then would that not make the Recipe Modifier system obsolete? What benefit is defining structural upgrades to a Modular Machine if the same could be done in the recipe file, and with exactly the same or more possibilities for customization? Why even have the system at all, in that case? I don't mean to say that anybody should immediately remove the system from the mod; quite the opposite, as i think it encourages pack makers to define their machines in such a way that they look aesthetically pleasing, and to give players a goal to work toward that will also make their machines aesthetically pleasing as well as mechanically satisfying.

• Defining the upgrade item in every recipe file might also encourage bad coding conventions, as it encourages copy-pasting the item definitions into every recipe for a particular machine, producing redundant definitions where it is not beneficial to have them. The IT world is big on removing non-beneficial redundancy, as we all know.

Cleaned up the suggestion tickets, so will archive this one as it's covered under a couple different ones already in the master ticket now.