@mipiano You are very observant!
Yes, the nested set data model for hierarchies is best suited for cases where you query often against it, but update rarely. So it does outperform tree structure for queries and underperform when the comparison is from the angle of updates. (Technically, both are tree structures, each using a different data model, but we all know what you mean)
For any database backend, keeping data integrity is something that developers need to be thinking about. In this case, integrity means that when updating the structure, we should modify all records we target at the same time or none at all. Anything preventing one record targeted from being updated should get the system to reject the overall update and leave the system in its original state, being the last known good state.
This can be achieved in FileMaker with transactions. That is a topic in itself, so I won't discuss more here, I believe there are some posts you can find about that, both here on fmSoup and on some blogs. I use the Karbon framework for my implementation of transactions.
The only implementation I did of the nested sets was for a demo file I gave for a French-speaking conference. It was simply to introduce the concept and the key differences with the more traditional approach. It was not made to be transactional, because it would have made the whole thing harder to understand (bringing too many new concepts together would simply blur the lines for people learning about those concepts).
I'm glad to see this piqued your interest. I hope you will also be looking into transactional scripting, as that technique can be crucial in a good number of cases.