Yes, that could very well be related to luasnip+formatting.
Could you do :lua Luasnip_current_nodes[vim.api.nvim_get_current_buf()].parent:dump() (prints the nodes' positions) after the text was duplicated? I'd assume the extmarks get messed up by the formatting (if a block of text is replaced, the marks that were inside it get pushed to either end).

:lua Luasnip_current_nodes[vim.api.nvim_get_current_buf()].parent:dump():

E5108: Error executing lua [string ":lua"]:1: attempt to index global 'Luasnip_curren
t_nodes' (a nil value)
stack traceback:
        [string ":lua"]:1: in main chunk

:lua require("luasnip").session.current_nodes[vim.api.nvim_get_current_buf()].parent:dump()

1
false false
0 0
0 0
2
false true
0 0
17 0
3
true false
17 0
0 0
4
false false
0 0
8 0
5
false false
8 0
8 0
6
false false
8 0
8 0
7
false false
8 0
8 0
8
false false
8 0
8 0
9
false false
8 0
8 0
10
false false
8 0
8 0

Yes that's the correct one :D 🤦
Normally these indices should be consecutive, here the marks are getting moved around.
Sadly there's little we can do about that (except manually tracking changes and not relying on extmarks, but that's very much work) :/

This is using efm to format instead of texlab:

1
false false
3 0
3 9
2
false true
3 9
3 11
3
true false
3 11
4 11
4
false false
4 11
4 13
5
false false
4 13
5 0
6
false false
5 0
5 0
7
false false
5 0
5 0
8
false false
5 0
6 10
9
false false
6 10
6 22
10
false false
6 22
6 28

Is this the normal behavior? Efm does not duplicate it, only texlab does that.

That looks correct, you can see that all nodes are adjacent ((3,0)->(3,9), (3,9)->(3,11),...), which is the correct behaviour.
I guess efm does something nicer, eg. not formatting at all or only inserting/removing parts that need to be changed as opposed to texlabs' complete replacement of the buffer.

Should no longer happen after 6e951d8, I think