If you are building a DAG, it is very likely that you don't want the rug to be pulled under you by GC. So having an additional temp_pin option guides you to correct API usage. I can't think of many cases where you would not want a temp pin when building a dag.
(When you get a dag from somewhere external, it is most likely that you get it via sync, so you don't really interact with individual nodes)
The current two separate methods are also a bit inefficient because they require two write transactions where there used to be one back when insert had an optional temp pin.
If you are building a DAG, it is very likely that you don't want the rug to be pulled under you by GC. So having an additional temp_pin option guides you to correct API usage. I can't think of many cases where you would not want a temp pin when building a dag.
(When you get a dag from somewhere external, it is most likely that you get it via sync, so you don't really interact with individual nodes)
The current two separate methods are also a bit inefficient because they require two write transactions where there used to be one back when insert had an optional temp pin.