Yep, in my case it was a storytelling tool for visual novel games, so there wasn't much data to pass around, most nodes were either modal interactions or affecting changes upon the game world. It's also a pretty constrained domain so a lot of the bookkeeping could be done internally rather than needing to be exposed to the narrative designer. A lot of the problems you mention just didn't need to exist.
In terms of how it was implemented (C#, for context), every possible node had to be a pure object (no internal mutation) with an asynchronous "run" method. This "run" method receives the game world as a parameter (Basically just a service locator. Services hold the mutable data).
At design time, we would instantiate the nodes and use reflection to display their fields to the designer, using specific widgets if the field was a pointer to another node. The design tool also kept an unique identifier for each node, and sorted by those on serialization. We used an ini-like custom format (hadn't heard of TOML at the time or would have probably gone with that) so that there was no nesting of nodes. Instead, fields that point to other nodes would just be serialized as the target's ID. When deserializing, we would have two passes, one reads the story file into an intermediate representation, so that every node is "known", and another to apply the actual properties (which can include references to out of order nodes).
But yes, as you mention, it is a system very fit for the domain, with some choices that don't make as much sense generally. Which is part of why I see that project as successful, and kind of demonstrates how much work goes into making a good visual scripting tool.