Hi,
>The problem here is that everyone on the list has his one favourite set
>of normal and weird cases.
That's true. For me, it's a weird use case if somebody moves a node twice
within the same *transaction* (from "a" to "temp" to "b"), and somebody
else *concurrently* removes the "temp". For me, it would be OK if the
transaction fails because "temp" was removed. I don't know what others
think about it.
>That means designing a potentially broken system ("Unless it turns out
>to be a problem in practice") right from the start...
No. By your definition every system is broken, because every system
doesn't solve "some" problem.
Every feature has a cost. I would try to avoid the cost of features nobody
actually needs. I would even argue good design is minimalistic (make it as
simple as possible but not simpler). But deciding which feature is
required isn't that simple of course.
Your solution certainly seems interesting, and I would keep it if
possible, with an option to disable it.
But I just don't know how useful it is in practice. If the use case
described above (concurrent delete of temp node) is really the only use
case then I think it's not worth it. I have the feeling there are other
use cases, that are more relevant.
Regards,
Thomas
