Sorry. I cannot reproduce the original bug.
Could you be more clear about what the original bug is?
And the precise steps to reproduce it.

The above is my steps to reproduce the behavior. Am I missing something?

Thanks for taking a look!
I tried to record a video of what I mean. The content is copied correctly and UUIDs are also correct. However for the root note that gets cut the references are no longer shown (I mean the 1 at the right of the block). After re-indexing this would appear again as the UUIDs are correct, however the :db/id doesn't get updated as somehow the :block/_refs are missing from what is returned by db/pull (not sure if this is expected or not).
The other (maybe) issue is that the references contain the old and new :db/id in their path-refs. This might not be an issue in practice, not sure.
In any case let me know if this makes sense or you'd like me to provide anything else.

Here are some details on the other problem:

After the cut the :block/ref is correctly gone. After the paste however the block will reference both the old and the new db/id of the block (so one will actually no longer exist). Do you have any idea what part of the code could cause this?

Thanks. It would probably be also good to address the problem of the stale :db/ids in the references. Without a fix to the problem of stale, non-existing, :db/id one runs into issues when interaction with the old blocks. (I see this in the console: #error {:message "Cannot store nil as a value at [:db/add 38443 :block/path-refs nil]", :data {:value nil, :context [:db/add 38443 :block/path-refs nil], :error :transact/syntax}}).

I found the problem with the references to old db/id. They are added via revert-cut-txs. Here is what revert-cut-txs looks like:

([:db/add 85 :block/refs 90]
 [:db/add 85 :block/path-refs 90]
 [:db/add 85 :block/content "((659f6f20-868f-421b-88c0-2c9bf0346461))"]
 [:db/add 81 :block/refs 99]
 [:db/add 81 :block/path-refs 99]
 [:db/add 81 :block/content "((659f6f26-8b03-4ad8-8b6b-0205c68130f3))"]
 [:db/add 88 :block/refs 94]
 [:db/add 88 :block/path-refs 94]
 [:db/add 88 :block/content "((659f6f27-5175-4054-9d7b-56e77d3f007c))"]
 [:db/add 81 :block/refs 99]
 [:db/add 81 :block/path-refs 99]
 [:db/add 81 :block/content "((659f6f26-8b03-4ad8-8b6b-0205c68130f3))"]
 [:db/add 88 :block/refs 94]
 [:db/add 88 :block/path-refs 94]
 [:db/add 88 :block/content "((659f6f27-5175-4054-9d7b-56e77d3f007c))"]
 [:db/add 88 :block/refs 94]
 [:db/add 88 :block/path-refs 94]
 [:db/add 88 :block/content "((659f6f27-5175-4054-9d7b-56e77d3f007c))"])

For example there is :db/add 85 :block/refs 90 which refers to 90, the old :db/id that no longer exists. Removing revert-cut-txs solves the issue here. However, the revert is needed to add back the block references instead of the copied text that that was inserted in the cut. One fix could be to remove the refs and path-refs from the revert txs. Another solution would be trying to preseve the :db/id from before the cut and not create a new :db/id. I'm not sure if there's a better solution. What do you think?

I updated the PR to not include references to non-existing :db/id in revert-cut-txs. This solves the issue for the problem I was facing. Note that :db/ids are removed in outliner.core.cljs in function insert-blocks-aux.

Let me know if this solution works. I don't have a good enough overview of the code base to know whether this would break something else. If there's another test case I should try also let me know.

Here's the behavior after the changes:

• all block references are there
• the blocks that contain the references only point to the existing :db/ids

Should we merge this or is there anything else missing?