> I think of them as 2 different nodes, 2 instances of the same type of ingredient.

But this is inconvenient during the shopping step of the process. There you want all uses of an ingredient (possibly across multiple recipes) collapsed into 1 node.

for sure! The use case I'm solving for myself is easy lookup while I'm cooking which is different than the use case of me going shopping

Maybe someday I'll add a feature to grab a shopping list. Could organise it into sections of the store and do a quick traveling salesman problem :D

also due to the conciseness of the grid, it's also not great if you're making it for the first time

Duplicating the nodes is also far from ideal when the reused node is not a raw ingredient but an intermediate with possibly complex dependencies itself. Duplicating the whole subtree would not be helpful.

> The use case I'm solving for myself is easy lookup while I'm cooking

This is a constant source of stress for me cooking from cookbooks I otherwise like. I prefer to measure on-demand, and wish the steps would just duplicate the quantities of the ingredients "whisk in the olive oil (1/4 cup)" instead of "whisk in the olive oil" so I don't have to scan the list of ingredients and figure it out

What if there was one further section in the left column that runs across the y axis and tallies ingredients?

That way there are three "segments" of the spreadsheet: shopping; prep; cooking.