E$1 is a reference pointing from column D relative to column E (+1 column). Of course, if you paste that into column B it will reference column C (still +1 column).
Not a bug.

Not solved. My description has mistakes. Look again into the following, please:

Steps to Reproduce claimed bug:
1. Open new Calc file.
2. Enter the number '1' into cell G1. Cell G1 now has the value '1'.
3. Enter the formula '=$G1' into cell D1. Cell D1 now has the value '1' same as cell G1.
4. Mark column D and enter key-combination Ctrl+C to copy marked column D.
5. Left-click on column B and select "Insert Columns Before".
7. Note how value '1' has shifted from cell D1 to cell E1 as it should. However, column D is still the copied cell as indicated with vertically moving interrupted lines around the column D.
8. Note that column B is still marked. 
6. Enter key-combination Ctrl+V to insert copied column D into column B. Cell B1 now has the value '0' instead of '1', because it is still referencing Cell G1 instead of H1.

Same steps bring correct reference and value '1' in Microsoft Excel.

My explanation:
When a column is added on the left side of marked/copied column D, the marked/copied column D's content shifts to the right and its reference shifts also +1 column, which is ok of course. However, the "marking of copy" doesn't shift to the right. It stays on column D, which I find wrong already. But let's say that is ok, we can at least agree that at this moment, column D has no value anymore since it was shifted +1 column. So at this state, if I press Ctrl+V, then it should at least paste no value because column D has no value. Instead, it pastes column D's old reference value, which is definitely wrong.

My fix proposal:
I believe the problem is fixed if the "marking of copy" also shifts when everything else shifts.
Or, take off the "marking of copy" when everthing shifts, so I am forced to recopy the correct column again.

Comparison to Microsoft Excel:
Microsoft Excel gives two options to add a new column while another has "marking of copy".
1. Add new column with a copy of marked column. Then, it takes off the "marking of copy", so that the user has to mark and copy it again if he needs it.
2. Add new column without a copy of marked column. Then also, it takes off the "marking of copy".

Conclusion:
Simplest solution in my eyes is to take away the "marking of copy" evertime new cells are added, so that the user is forced to start a new copy procedure. This is what Microsoft Excel does.

Sorry for the long text, I hope this makes sense.

The numeration of the steps are wrong this time xD .. Sorry. The steps are correct in order from top to bottom.

Let's keep the bug in unconfirmed status until someone else can confirm it. Other way, no one will look on it.

(In reply to milchreis from comment #2)
> Steps to Reproduce claimed bug:
> 1. Open new Calc file.
> 2. Enter the number '1' into cell G1. Cell G1 now has the value '1'.
> 3. Enter the formula '=$G1' into cell D1. Cell D1 now has the value '1' same
> as cell G1.
> 4. Mark column D and enter key-combination Ctrl+C to copy marked column D.
> 5. Left-click on column B and select "Insert Columns Before".
> 7. Note how value '1' has shifted from cell D1 to cell E1 as it should.
> However, column D is still the copied cell as indicated with vertically
> moving interrupted lines around the column D.
> 8. Note that column B is still marked. 
> 6. Enter key-combination Ctrl+V to insert copied column D into column B.
> Cell B1 now has the value '0' instead of '1', because it is still
> referencing Cell G1 instead of H1.
> 
> Same steps bring correct reference and value '1' in Microsoft Excel.

I tried in office.com's Excel and nothing is pasted in the last step. I used "Insert columns to the left".

On desktop Excel version 2407:

(In reply to Buovjaga from comment #5)
> (In reply to milchreis from comment #2)
> > 5. Left-click on column B and select "Insert Columns Before".
I used Home ribbon > Cells section > Insert > Insert sheet column, which is the equivalent column.
> > 7. Note how value '1' has shifted from cell D1 to cell E1 as it should.
> > However, column D is still the copied cell as indicated with vertically
> > moving interrupted lines around the column D.
No dashed rectangle anymore.
> > [9]. Enter key-combination Ctrl+V to insert copied column D into column B.
> > Cell B1 now has the value '0' instead of '1', because it is still
> > referencing Cell G1 instead of H1.
> > Same steps bring correct reference and value '1' in Microsoft Excel.
Just like Ilmari: no paste action recorded, nothing in column B.

Which Excel version are you using? Please check again your steps and results.

(In reply to Stéphane Guillou (stragu) from comment #6)
> [...] which is
> the equivalent column.
the equivalent *command*.

Thank you for the questions. Here checked my steps and results again, same bug happens.

Tried on the newer software versions:
LibreOffice Version 24.2.5.2
Microsoft Excel 2021 Version 2407

LibreOffice Calc:
1. Open new Calc file.
2. Enter the number '1' into cell G1. Cell G1 now has the value '1'.
3. Enter the formula '=$G1' into cell D1. Cell D1 now has the value '1' same as cell G1.
4. Click on column D to mark whole column D, then enter key-combination Ctrl+C to copy marked whole 
column D. Note the interrupted lines moving around column D indicating that it is copied.
5. Right-click on column B, note how whole column B is marked, and select "Insert Columns Before".
6. Note how values '1' have shifted from cell D1 to cell E1 and from cell G1 to cell H1 as they should. However, column D is still the copied area as indicated with moving interrupted lines around column D.
7. Note that column B is still marked. 
8. Enter key-combination Ctrl+V to insert copied column D into column B. Cell B1 now has the value '0' and its formula shows =$G1. This is wrong because column B should be the copy of column D, which it isn't.

Microsoft Excel:
1. Open new blank workbook.
2. Enter the number '1' into cell G1. Cell G1 now has the value '1'.
3. Enter the formula '=$G1' into cell D1. Cell D1 now has the value '1' same as cell G1.
4. Click on column D to mark whole column D, then enter key-combination Ctrl+C to copy marked whole 
column D. Note the interrupted lines moving around column D indicating that it is copied.
5. Left-click on column B, note how whole column B is marked, and select "Home -> Cells -> Insert -> Insert Sheet Columns".
6. Note how values '1' have shifted from cell D1 to cell E1 and from cell G1 to cell H1 as they should. However, column D is no longer indicated with moving interrupted lines to be copied, and so the LibreOffice Calc bug cannot even happen on Microsoft Excel. The solution to the LibreOffice Calc bug is to also take off the interrupted lines and so the copy of the column D as soon as cells get shifted around.
7. Note that column B is still marked.
8. Enter key-combination Ctrl+V, but correctly nothing happens as nothing is copied anymore. So, no wrong value/reference can be copied after the shift of cells, which correctly forces the user to make a new copy.

(In reply to milchreis from comment #8)
> Microsoft Excel:
> 1. Open new blank workbook.
> 2. Enter the number '1' into cell G1. Cell G1 now has the value '1'.
> 3. Enter the formula '=$G1' into cell D1. Cell D1 now has the value '1' same
> as cell G1.
> 4. Click on column D to mark whole column D, then enter key-combination
> Ctrl+C to copy marked whole 
> column D. Note the interrupted lines moving around column D indicating that
> it is copied.
> 5. Left-click on column B, note how whole column B is marked, and select
> "Home -> Cells -> Insert -> Insert Sheet Columns".
> 6. Note how values '1' have shifted from cell D1 to cell E1 and from cell G1
> to cell H1 as they should. However, column D is no longer indicated with
> moving interrupted lines to be copied, and so the LibreOffice Calc bug
> cannot even happen on Microsoft Excel. The solution to the LibreOffice Calc
> bug is to also take off the interrupted lines and so the copy of the column
> D as soon as cells get shifted around.
> 7. Note that column B is still marked.
> 8. Enter key-combination Ctrl+V, but correctly nothing happens as nothing is
> copied anymore. So, no wrong value/reference can be copied after the shift
> of cells, which correctly forces the user to make a new copy.

Ok, so your opinion is that the non-action would be correct, essentially that the clipboard would be cleared, if new columns or rows are inserted. It seems rather disruptive. I tested it again in office.com and indeed, the clipboard is cleared irrespective of the content in the column.

Let's ask UX team.

(In reply to Buovjaga from comment #9)

> Ok, so your opinion is that the non-action would be correct, essentially
> that the clipboard would be cleared, if new columns or rows are inserted. It
> seems rather disruptive. I tested it again in office.com and indeed, the
> clipboard is cleared irrespective of the content in the column.


Please stop dumbing down Calc features. This is an advantage in Calc, not a bug.

When you consider that something should be blocked (i.e. not allowed) from happening (for everyone), please first ask yourself whether you would be also blocking some other use-case in which the behavior could be positive.

Since you are comparing to Excel... Excel cannot achieve the (undesired) result described in this ticket, but it can't achieve any other result either. Excel is capable of "copy+immediately_paste"; every action after "copy" that is not "paste" will block the access to the clipboard.

For the purpose of this ticket, the procedure is to first insert the extra new column, and then copy+paste. This would be the same in Excel.

This should be NAB.

Yeah, on second thought, let's skip bothering UX team with this. The request is highly controversial and would be a worsening of Calc.

There is a misunderstanding here.

This is a bug because LibreOffice Calc shows one thing, but does another thing.

I did not intend to suggest to dumb down anything on LibreOffice Calc. I'd rather enhance it because LibreOffice Calc is my preference over Microsoft Excel. You mentioned it and I agree, Microsoft Excel blocks the access to the clipboard, which I don't like.

That being said, I did make a "suggestion" to make it like Microsoft Excel to avoid the bug, yes. But I never intended to "request" anything other than resolving the bug. I don't have the expertise to request a certain solution. I just wanted to report the bug and see it resolved. My expression of a suggestion was only intended to describe the problem better to you since the problem is a weird nature, not so straight forward to understand.

I came here and used my own time for LibreOffice Calc to get better, and I thought it was intended for the User to report bugs to make that happen. That's all, I don't even know what "UX" means, and I didn't think I'd be bothering anyone, rather I thought I am helping someone.

You may see it as resolved and as not a bug. I can say that I have tried explaining that it is otherwise. I won't touch it from here.

Thanks again for your time, trials and efforts. Have a good time.

(In reply to milchreis from comment #12)
> There is a misunderstanding here.
> 
> This is a bug because LibreOffice Calc shows one thing, but does another
> thing.

No, that's not what happens. You interpret the "marching ants" selection border to mean "this exact thing will be pasted somewhere when I hit Ctrl+V". This is what I read from statements such as "at this state, if I press Ctrl+V, then it should at least paste no value because column D has no value". What actually happens is that the data is put into the clipboard immediately when you hit Ctrl+C/X. The clipboard is a snapshot of a state, it should not mutate after doing other actions.

(In reply to milchreis from comment #2)
> I believe the problem is fixed if the "marking of copy" also shifts when
> everything else shifts.

Actually now I found there is an existing request for this, bug 74374, so let's close as duplicate.

*** This bug has been marked as a duplicate of bug 74374 ***