Introduction
This is CREATIVE ONLY bug using commands (clone command, to be exact) so it does not need to be fixed immediately, but it needs fixing anyways, because fixing this would open many more possibilities, that are currently stagnating, because of this bug. It could be used in map/minigame making in various ways.

Logic behind my thoughts
When certain block is cloned, f.e. some crops (let's go with potato), the cloned potato will have the exact same properties as original potato (f.e. growth stage two), but they will not be fully grown at the same tick, because after cloning both of them are independed plants.

And when command clone with specifications (arguments) replace move is used, the argument itself indicates, that the original block was MOVED, because there technically never existed second cloned version of that block.

Description:
CASE 1:
When the LODESTONE is cloned with arguments replace move (so it is technically moved), it SHOULD retain properties of the original lodestone, including all lodestone compasses, that are locked to it. But the position where lodestone compasses should point to should also change to the current lodestone placement.

But after moving the lodestone (since lodestone is naturally immovable block, so it can not be moved by piston - even tho it makes no sense, because netherite, and all it's versions, is completely movable - therefore the clone move command is only option) all lodestone compasses locked to that specific lodestone start behaving like the original lodestone was destroyed and no longer exists. And when I tried to tap at them repeatedly (to re-lock compass to that moved lodestond), NOTHING changed, it was still spinning like crazy. That is also the thing for brand new compass - when locked to that moved lodestone, it changes itself to the lodestone compass, but it behaves exactly like the original lodestone compass - broken. Even restarting the game will not help.

CASE 2:
When the lodestone, with a compass already locked to it, is ONLY cloned (f.e.: "/clone ~~~ ~~~ ~~~6"), lodestone compass points to the original lodestone (and that's right in my opinion), but when I tried to lock new compass to the other (cloned) lodestone, IT STARTED to point to the original one. When original lodestone was destroyed, lodestone compasses started to behave as there was no lodestone (spinning) and the cloned lodestone was broken in exact same way as the moved one. BUT when lodestone with no compass locked to it was cloned and compasses were added to the lodestones after the cloning, both of the lodestones worked independently, like they were completely separately placed blocks (In this case this is the edpected and right behaviour, and with just clone, this is, how it should work)

I also tried to clone lodestone again, but now not 6 blocks apart, but 600 blocks from each other (i used my alter account to load the final destination area, tickingarea can be used so) and after that I unloaded (sim. distance sat up to 4 chunks) the area with the original lodestone and tried to lock new compass to the cloned lodestone [EXPECTED BEHAVIOUR: As in _CASE 2_, it was expected the lodestone compass will point to the original lodestone]. Everything went just as described upwards, so I think (via empiric testing), that if the block is loaded or not, doesn't matter.

Testing
I performed empiric testing on my android phone (mainly) as well as on my PC (Windows 10 edition). Results were exactly the same, so I am pretty sure that is NOT device based bug, rather mechanic-based one. (It isn't hard to reproduce)
MOBILE EDITION: 1.16.0; 1.16.1; 1.16.20 (beta)
WINDOWS 10 EDITION: 1.16.1

Expected behaviour
When lodestone is moved using clone command with arguments replace move, the lodestone compasses should redirect to the lodestone's new location.

Demonstration
This is a YouTube link to the unlisted video I made showcasing and explaining this bug: https://youtu.be/qlH4scIdEpQ

Potential usage
Map making
Minigames

(I was really excited for this feature, because I thought I can finally make vanilla player tracking systems without changing worldspawn, that could work in multiple dimensions and with multiple players. But this silly little bug destroys everything, so PLEASE, fix it)

Thanks for Your attention!