Yeah I find this bug to be rather troublesome as well. It also deters me from using Move Block because I wouldn’t want to accidentally move a block with a block-id on it that I can’t see.
Another user spoke up about it in the discord server but received very little response:
Lately I have noticed that block references break very easily (I am not sure if that’s a recent regression, or that’s how it behaved)
Let’s say I am referrring to some block using the (( … )) syntax. If I edit that block, or move that block to a different page, all those (( … )) break i.e. they show in red.
Should Logseq auto-factor the block references when a block’s UUID changes? Logseq v0.6.6 Windows (edited) @kaushalmodiDiscord message
Maybe I’m not using the proper keywords to find related posts on the forum, but if there has been a previous post about this before we can merge them.
Alternative Solution
Maybe the block UUID could be visible as a property like aliases etc. Even better it is only visible when we are editing the block so that it’s easy to move it from one block to another. When it’s the UUID is visible we can at least manually do a global search to see where the new block ended up and link it back again.
for me, the move block plugin has been a bit buggy. The blocks either go missing or the block id’s still break, maybe that has changed in the recent versions of the plugin and logseq.
One plugin that has worked well with moving around blocks safely was the swap block plugin. there’s the extra step of referencing the block you want to move first before swapping the blocks, but they haven’t broken the references in other locations in my notes so far.