Maybe a bit late, but I can confirm you.
The OR-logic strictly applies to the acceptance and consumption of the goods, which results in unexpected behaviour. Lets say we have a machines factory which has the input goods { "WOOD" , "STEEL" , "ALUMINUM" }. An realistic rule would be { 1,1,0 }, { 1,0,1 }, which one would expect to work as follows: One output element of "MACHINES" is produced by a combination of one input element "WOOD" with one input element of "STEEL" or "ALUMINUM" (so "WOOD" AND ("STEEL" OR "ALUMINUM")). What will actually happen is, that it will just consume all three input elements if they are present in the factory storage (so "WOOD" AND ("STEEL" AND "ALUMINUM")). As a result in this case, if you perfectly supply the factory so that each input good is always present in the factory storage, the actual production will on average be reduced by 1/3. In tyour case {1,0},{0,1} it will even be reduced by 1/2.
Now, if no "ALUMINUM" is present in the storage, it will also produce one element of "MACHINES" with only one element of "WOOD" AND "STEEL", and the other way around. This is surely unexpected behaviour as it punishes you for supplying more input goods.
It is a pretty simple problem actually: The consumption of different combinations of input elements is now linked with OR per output element. It should rather be XOR to represent real world behaviour. This should of course only apply to consumption, not for the acceptance.
I will write an email to URBAN, maybe they can change it in the final version.
edited for clarity...