Recipes are not a tree.
I was implicitly assuming that your graph models instructions and procedures. You seem to assume that the graph models concrete physical items.
You can execute the same steps twice, but you can't eat the same piece of butter twice.
When you come back to do the "same" operation again, you're fundamentally dealing with different items, even if it doesn't appreciably appear to be the case.
You might have different criteria for evaluation, but something has fundamentally changed.
Let's look at the simplest case you might be tempted to model as a cycle:
> "Salt to taste"
Now, that would traditionally be modelled in a flowchart as a cycle:
1. Add salt
2. Test taste. Too little salt? Go to step 1. Else go to step 3.
3. End.
However, in strict modelling terms, I'd argue there's a hidden parameter, "number of saltings attempted".
You wouldn't repeat that a hundred times and keep adding salt, after a while you'd suspect that your taste-buds had gone or the salt had gone funny.
So rather than a cycle, it's actually a series of steps with a hidden step counter, which eventually has different outcomes.
Have a look at the example of a turnstile state machine on Wikipedia: https://commons.wikimedia.org/wiki/File:Turnstile_state_mach...
The graph of that state machine suggests that you repeat the cycles indefinitely. But I have it on good authority that real world turnstiles only have a finite coin box. [citation needed] So there's some extra hidden state.
https://news.ycombinator.com/item?id=41700416
In particular the lemon meringe pie. You separate whites and yolks to prepare the filling and the meringue separately before merging them in the last step.
>it'd be a false re-use
Technically, recipes are monoidal pre-orders and I guess you could find arguments against what you propose in the mathematical foundation, unfortunately I'm not versed enough in category theory to articulate it properly.
For example, if you make the "Lobster, Poached with Shellfish, Pear, and Kale" from the 11-madison park cookbook, you will make a "white balsamic vinaigrette" which is then used directly to make the "Pear Glaze", "Pickled Mustard Seeds", and "Pear marmalade" components. (The pickled mustard seeds also go into the "Pear marmalade" component.)
I think the post you're replying to is saying that you'll make 3 "white balsamic vinaigrettes" instead of reusing the same one 3 times.
Which makes sense since one step of the recipe will be to divide the vinaigrette into 3 amounts to make the other ingredients.
You'd only have one node. Just like you don't put every bite of food into its own node.
If you have a recipe that uses 150g flour in step 1, then later uses 350g flour in step 4, then you actually have two separate ingredients:
1. 150g plain flour
2. 350g plain flour
It may useful to present an ingredient summary for the purposes of shopping which collects that to 500g flour, but from when trying to represent the recipe, it's actually two different ingredients, and it'd be a false re-use to try to re-use the node or try to treat those ingredients as a single ingredient of greater quantity.
Just because two things appear otherwise identical, doesn't mean they are.
I sometimes see a similar issue in software development and re-use of classes or functions. Two different cases happen to need identical handling, so get put through the same code paths. Then later it turns out one case needs to be treated slightly differently, so that path ends up with special casing, and you get a mess of special handling with case statements or "bool treatDifferently" parameters.
If things are conceptually different, then treat them differently, don't assume false commonality.