I would refrain from this convenience feature. Like any other automatic interaction it may result in the opposite. For example you select a column and right click / insert before - wouldn't you expect the selection to be persistent to not loose the overview? So my take here is WONTFIX as the use case is undefined (or just for convenience).

On the other hand Calc works exactly like suggested. Focus stays on B1 when you insert a column left, meaning the cell content is moved to the right. In Writer the focus remains on the current input and the selection moves with the input. (I prefer the Writer way here.)

Opinions?

Created attachment 140060 [details]
Example

It's a rather small bug, I'm aware of that. I know only one user case. Say, I have small screen device (Windows Surface; iPad, or like a Macbook Air 11 inch). I'm looking at single page table. zoomend in (making it readable). Seeing only half a page (or less). I want to a add a new row, between the existing ones. 
(a) Clicking on the 'add row below' doesn't seem to work; no visual change
(b) I have two swipe to the new row. Which can be hard if the table cell is rather large (key down will work for keyboard, but not for other swipe only devices)
(c) I sometimes want to add a few rows (say 5), so I click on add a new row multiple times. I can't actually how many a added; I have to really count the clicks)
(d) A non argument: It's a bit of a workaround for the table autosave jumping bug. You have to restart of swiping for the freshly added row if the autosave kicks in while swiping..

Another reason I noticed it is because quite a lot of programs do scroll. For example Google Docs, Microsoft Word.

In the general case there are uses for supporting such movements in the GUI.

Clearly as here where some movement is needed. And other areas, for example bug 105610, where repositioning the edit cursor focus and panning the view of the document canvas to a consistent position (centered L/R & T/B) is going to be needed.

But think that would need to include dropping a mark/reminder of some sort for a return of positioning (i.e. for using Navigator in Reminder mode).

(In reply to Telesto from comment #0)
> Adding a new row (above/below) has no effect on the mouse cursor. I would
> expect it to move the new row. 

It does not have in Calc either..

Is component 'Writer' the right one? If changed, it should be changed in all components as well as in Calc.

(In reply to Heiko Tietze from comment #1)
> On the other hand Calc works exactly like suggested. Focus stays on B1 when
> you insert a column left, meaning the cell content is moved to the right. In
> Writer the focus remains on the current input and the selection moves with
> the input. (I prefer the Writer way here.)
Calc only works as intended in this bug report if you insert columns left or rows above. Not for columns right and rows below (because in fact the selection doesn't change).

I'm not in favor of changing neither keeping the behavior, I haven't paid attention to this in the past to say what's better.

But if we change it, to which cell should the cursor moving especially in RTL, CTL, CJK languages when several rows/columns are added? In LTR it's the top-left cell I assume. In Calc it's easier as the whole cell selection should move to the newly added rows/columns.

Taking into account that any solution would have uncertainties and likely ends up in inconsistent behavior plus the doubts on the use case, the recommendation after discussion in the design meeting is WONTFIX.