This is somewhat related to the two previous bugs that I've submitted (both have been fixed), the most recent being #511481. I am running Zim 0.48 on Debian.
I've noticed something potentially improper when renaming a page with children in the specific case that the contents of those children reference each other. Following the format for creating an example that I used in the aforementioned bug report, consider the following simple hierarchy:
* TheParent "Loves [+FirstChild] and [+SecondChild]
** FirstChild "Hates the [SecondChild]"
** SecondChild "Loves the [FirstChild]"
If you rename TheParent to anything else, all of the following happens:
* TheParent is renamed to the new name (that makes sense)
* The relative link from TheParent to Child1 is preserved (that makes sense)
* The relative link from TheParent to Child2 is preserved (that makes sense)
* The content of Child1 is transported to a new page underneath the renamed parent (that makes sense)
* The link from Child1 to Child2 is converted from a relative link into an absolute link that reflects the OLD hierarchy, which no longer exists (that doesn't make sense)
* The content of Child2 is transported to a new page underneath the renamed parent (that makes sense)
* The link from Child2 to Child1 is converted from a relative link into an absolute link that reflects the OLD, which no longer exists (that doesn't make sense)
While I can actually see some advantage to calling this behavior a feature rather than a bug, I think that this simple example suggests just how much havoc such functionality could bring to a well organized notebook. The simple act of renaming a page should not irreversibly break a notebook and its references.
I suspect that the issue may go even deeper. Using the same initial sample hierarchy outlined above, instead of renaming TheParent create a new page called NewParent. If you move Child1 underneath NewParent then the link from Child1 to Child2 is converted into an absolute link and the link from Child2 to Child1 is converted into an absolute link. This makes sense. If you then move Child2 underneath NewParent then the link from Child1 to Child2 is converted back into a relative one, and the link from Child2 to Child1 remains absolute but correct. Technically, this makes sense, but it's not really what you want. What you want in this case is for both links to be relative again at the end like they were in the beginning. However, I understand the limitation. You basically have to make a decision that all links are either going to be aggressively re-factored into relative links whenever possible or always expanded out into full, absolute links. However, this simple moving example doesn't really do either. One is link ultimately has its relativity preserved while there other has it destroyed. It's not consistent. Moreover, it doesn't change the fact that the page renaming issue outlined above is very unacceptable.
I apologize for adding onto this before my original comment was reviewed, but further testing has confirmed my that multiple behaviors are conspiring together to deliver an inconsistent and unpleasant workflow.
Basically, I attempted a manual "work around" of the bug described above. My "work around" was simply to convert the relative links of a sample notebook into hard-coded absolute links. The renaming of the parent was successful in the sense that the links of the children did update to the correct locations and didn't leave behind any references to the prior hierarchy. However, after the links were correctly updated they were then automatically collapsed down to relative links again. Thus, if I wanted to change the name of the parent again, I was back in the exact same position as I was before I my manual "work around".
I agree that the automatic collapsing of links down to their relative form IS the most desirable behavior. However, if this is going to be the default behavior then the issue which is the source of this bug report must be fixed. Otherwise, it's not only undesirable but also exacerbated by the behaviors of other commands.