My formula in D20: =A11*2

Arch Linux 64-bit, KDE Plasma 5
Version: 5.4.0.0.alpha0+
Build ID: 1fce5b024e9f25c3fcef2537a22474ece0dc416f
CPU Threads: 8; OS Version: Linux 4.8; UI Render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on December 10th 2016

Arch Linux 64-bit
LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4

Versione: 6.1.0.1
Build ID: 378e26bd4f22a135cef5fa17afd5d4171d8da21a
Thread CPU: 2; SO: Linux 3.16; Resa interfaccia: predefinito; VCL: kde4; 
Versione locale: it-IT (it_IT.UTF-8); Calc: group threaded
(https://gerrit.libreoffice.org/gitweb?p=core.git&a=log&h=378e26bd4f22a135cef5fa17afd5d4171d8da21a)
 Default settings (clean config)

I confirm I can reproduce this bug.
But, isn't it the normal behaviour of Calc that, when you copy a cell, referring to another cell, the references got updated accordingly and, if you paste the cell too far to the left (or above) the pasted cell, you end up pointing to a non-existent cell?
I.e. for example in case 1, D20 should finally be pointing to {A-6position to the left}{1+10position to the bottom} that is  #REF!11
and, for case 2, if I have 1 in A1 and =A1 in B2 if I copy-paste B2 in B1 I got =#RIF!1 (as I would expect); if I copy-paste B2 in D20 I got 0 (i.e.: =C19)...
Should it be normal (as I thought) or should default behaviour be different?

Hmm, it seems Ascaf is right and actually I get the *same* result now without any row insertions! That is, =#REF!20*2 after pasting in D20. A similar result is indeed seen in any paste to the left of G column.

Let's close.

> But, isn't it the normal behaviour of Calc that, when you copy a cell,

Yes, but the report is not about copying. It is about cutting.

So, this is the formula in D20 after the following procedures:

A. Cutting G10, no row insert, paste in D20: =A1*2

B. Cutting G10, row 2 insert, paste in D20: =#REF!11*2

C. Copying G10, no row insert, pate in D20: =#REF!11*2

D. Copying G10, row 2 insert, paste in D20: =#REF!11*2

Cases C and D are about copying and are consistent. Cases A and B are about cutting and are inconsistent.

In case B, "cut" is adopting "copy" behavior.

I think this is the intent of the original bug report.

Indeed, sorry for sloppy testing back there.

Thanks for the explanation. So I thought it might be interesting to check the clipboard while doing the usual sequences and to see if the inconsistencies were triggered by action different from adding row.
In particular I got this (below, with klipper I mean the values stacked in the clipboard, newest to the right):

IN new spreadsheet: A1 --> 100
g20 --> =A1*2 (200)
g20 --> ctrl-x
klipper: 200 (the value on the clipboard stack)
d20 --> ctrl-v
now d20 is 200 (=A1*2)
klipper: 200 (unchanged)
d20 --> ctrl-v (accept overwriting)
now d20 is #RIF! (=#RIF!11*2 like if cutting-pasting)
klipper: 200, #RIF! (the same value you'll get if you copy-paste instead of cutting-pasting)
keep on overwriting (if you want) but the value will not change any more)

for comparison with copy-paste
IN new spreadsheet: A1 --> 100
g20 --> =A1*2 (200)
g20 --> ctrl-c
klipper: 200
d20 --> ctrl-v
now d20 is #RIF! (=#RIF!11*2)
klipper: 200, #RIF! (the value pasted has been updated, in accordance with the internal rules, I suppose)

So it seams the simple action of pasting twice triggered some formula updating to the clipboard?

(In reply to Ascaf from comment #7)
> Thanks for the explanation. So I thought it might be interesting to check
> the clipboard while doing the usual sequences and to see if the
> inconsistencies were triggered by action different from adding row.
> In particular I got this (below, with klipper I mean the values stacked in
> the clipboard, newest to the right):
> 
> IN new spreadsheet: A1 --> 100
> g20 --> =A1*2 (200)
> g20 --> ctrl-x
> klipper: 200 (the value on the clipboard stack)
> d20 --> ctrl-v
> now d20 is 200 (=A1*2)
> klipper: 200 (unchanged)
> d20 --> ctrl-v (accept overwriting)
> now d20 is #RIF! (=#RIF!11*2 like if cutting-pasting)
> klipper: 200, #RIF! (the same value you'll get if you copy-paste instead of
> cutting-pasting)
> keep on overwriting (if you want) but the value will not change any more)
> 
> for comparison with copy-paste
> IN new spreadsheet: A1 --> 100
> g20 --> =A1*2 (200)
> g20 --> ctrl-c
> klipper: 200
> d20 --> ctrl-v
> now d20 is #RIF! (=#RIF!11*2)
> klipper: 200, #RIF! (the value pasted has been updated, in accordance with
> the internal rules, I suppose)
> 
> So it seams the simple action of pasting twice triggered some formula
> updating to the clipboard?

Sorry above read g10 instead of g20:

IN new spreadsheet: A1 --> 100
g10 --> =A1*2 (200)
g10 --> ctrl-x
klipper: 200 (the value on the clipboard stack)
d20 --> ctrl-v
now d20 is 200 (=A1*2)
klipper: 200 (unchanged)
d20 --> ctrl-v (accept overwriting)
now d20 is #RIF! (=#RIF!11*2 like if cutting-pasting)
klipper: 200, #RIF! (the same value you'll get if you copy-paste instead of cutting-pasting)
keep on overwriting (if you want) but the value will not change any more)

for comparison with copy-paste
IN new spreadsheet: A1 --> 100
g10 --> =A1*2 (200)
g10 --> ctrl-c
klipper: 200
d20 --> ctrl-v
now d20 is #RIF! (=#RIF!11*2)
klipper: 200, #RIF! (the value pasted has been updated, in accordance with the internal rules, I suppose)

Repro

Version: 7.2.0.0.alpha1+ / LibreOffice Community
Build ID: 98a8d8bc15018576e1312493425d7bb3725be735
CPU threads: 4; OS: Linux 5.3; UI render: default; VCL: x11
Locale: de-CH (en_US.UTF-8); UI: en-US
Calc: threaded

The problem is that Calc knows how to do "cut" and _immediately_ _one_ "paste", but does not know how to do the _same_ _exact_ "paste" if that action is not immediately after the initial "cut". Any "paste" action that is not the first and immediate action after the initial "cut" action will work as "(copy+)paste". This is also true for several (adjacent, vector) cells selected at once for pasting in the first immediate step – only the first pasted cell will have the same exact formula, whereas the others will behave as copy+paste.

So, in Calc, when doing cut, insert (cells), paste, the resulting paste is not the same as cut and paste, but rather a copy and paste.

And when repeating the first immediate paste after the initial cut, the result is also not the same as the first paste, but rather it works as a "copy+paste".

Example:
1. A1: 100
2. B2: =A1*2
3. Cut B2. Note the surrounding "ants" around B2.
4. First immediate paste on D3. Result: =A1*2. Note the surrounding "ants" around B2.
5. Paste on E3. Paste on D4. Paste on B3. Note that the resulting formulas are equivalent to copying the initial B2 (still surrounded by "ants") and then pasting that on E3, D4 and B3 respectively.
6.  Paste on A3. The behavior is exactly the same as step 5. With the current behavior, there is no alternative but to result in =#REF!2*2.


In order to repeat the same formula several times in Calc, there are a couple of options: either use absolute references before cutting, or you have to cut the formula itself from within the input window formula bar. Unfortunately, in the second case the corresponding paste action(s) will only paste the formula, not the cell's format.

Other spreadsheet tools might work differently.

One possibility is to transform this report into a request for enhancement (or starting a new one), allowing to paste the initially cut cell multiple times "as-is", or even when other non-clipboard actions are performed in between.