I created a sample document with columns (= heading contents) 1,2,3,4) and
further contents a shown for my tests with "2.2.1  Multilingual German version
WIN XP: [680m18(Build9161)]":

1  2  3  4  
a  b  c  d
e  f  g  h
i  j  k  l

@asb 
I believe we talk about the following effect:

1. mark cells with contents "a ... d"
2. <cntrl>+<c>
3. mouseclick into cell with "e"
4. <cntrl>+<v>
   expected by user "asb": new row with contents "a ...d" should be inserted,
                           row with "e ..." should be shifted
   actual: "e  f  g  h" will be overwritten with "a  b  c  d"

I can not see anything wrong here. What would be your concept for marking 
b  c
f  g
copy and paste it after click into cell with "g"? Or if you want to insert the
row contents into an other cell with more rows and columns?

The current behaviour is the most predictable one and so, as I belive, the best one.

Because I can not find any hint in documentation that predicts a behaviour as
preferred by "asb", this seems to be no defect.

Because "asb" did not contribute a stringent, logical and comprehenceble concept  
for his wishes, I believe this issue should be set to "invalid".

@rainerbielefeld

Counterquestion: What is your concept for rearranging the rows of a table, e.g. 
a timeline consisting of a few hundred rows?

If you have to move the row "a  b  c  d" below "e  f  g  h", you'll (a) either 
mess up the table's contents completely (if you're used to the behaviour of 
Microsoft programs), or (b)

1. Mark the row "a b c d", copy it's contents
2. Move to the row "i j k l"
3. Click on the menu "Table" or type <Ctrl+t> (in German OOo),
4. Select "Insert" or type <Ctrl+g>
5. Select "Rows" or type <Ctrl+z>
6. Click on "Position: Above" or press <Return>
7. Paste the contents from the clipboard
8. Move up to the former row "a b c d"
9. Select "Table"/"Delete"/"Rows" or press <Ctrl+t>+<l>+<z>

That's a lot of clicking/typing to simply move _one_ row of a table. If you 
have to rearrange a few hundred rows, this might be driving you insane. In 
Microsoft applications and compatibles, all this can be done completely by 
using the mouse _and/or_ keyboard shortcuts, but with significantly less 
clicking/typing (Mark a row, move the cursor to the insertion point and type 
<Alt+d>+<l>, if I remember correctly; I can look this up, if anyone is 
interested; anyway, it's _a lot_ faster).

I think their (Microsofts and those of compatible apps) usability approach is 
to honor the _context_ of the operation; it recognizes if you want to do an 
operation on single cells or complete rows; if you're working on rows, the 
mouse pointer "tilts" a few degrees to the right and marks the complete row; if 
you select single cells or all cells of a row, but not the row itself (!), the 
mouse pointer as well as the inverted colour of the marked section(s) look 
different. This gives a very good feedback to what you're doing.

Thus I'd suggest that OOo Writer should allow context sensitive operations. Of 
course it doesn't necessarily have to mimic the behaviour of Microsoft-style 
apps, but it _should_ allow similar operations, and should be operatable at 
least as fast as "Word" and consorts.

Besides this usability aspects I'd like to stress again that the expected 
behaviour when _inserting_ something is that something is inserted and not 
something else is overwritten. If OOo currently can not honor the context of 
user operations, as Microsoft apllications do, it should at least honor the 
setting of the "Insert/Overwrite" key. If it's set to "Overwrite", OOo Writer 
could behave as it does now, if it is set to "Insert", it should insert the 
full row as a _new_ row.

As to the question what I would expect if marking the block "b  c" and "f  g", 
and then copy and pasting it after click into cell with "g": These are _cell_ 
operations, not _row_ operations, so they could and should behave differently.

Example to prove my point: Mark the block "c d" and "g h", copy it, move to 
"l", and insert it; OOo adds a _new_ row with the contents "_ _ _ g" (the 
underscores are suppose to signify empty cells). 3/4 of the contents to be 
pasted gets lost - that's usually not what a user expects.

For block operations, there are three ways to deal with tha I can think of:

1. Honoring the context of the operations (as described above);
2. Operating in a special block mode, a function most text editors provide;
3. Inserting the full cutted construct at the insertion point, as e.g. Mozilla 
Composer and derivates does (if you cout some cells from a table and insert 
them anywhere else, a new mini-table is inserted on the insertion point).

(3) appears to me at least as logical as the current behaviour of OOo, but it's 
IMHO not very user friendly; thus I'd suggest (1), especially when honoring 
position of the  "Insert/Overwrite" key.

I'll try to sum up something which is complex and will need a lot of redesign...

To be defined following behaviors in a future specification.

Table sample:
1  2  3  4  
a  b  c  d
e  f  g  h
i  j  k  l

1) Moving a row (same for columns):

1.1) With the mouse
- Select  a  b  c  d
- Drag/drop to i
-> the table should look like this:

1  2  3  4  
e  f  g  h
a  b  c  d
i  j  k  l

1.2) With the keyboard:
- Select  a  b  c  d
- Use a keyboard shortcut (TBD) like Ctrl+Alt+Up/Down which is currently used to
move paragraphs.
-> the table should look like in 1.1) after pressing 2 times Ctrl+Alt+Down.

1.3) By Copy/Paste (not so easy!):
- Select  a  b  c  d
- Cursor in i
- Paste

-> OOo replaces the current row:
1  2  3  4  
a  b  c  d
e  f  g  h
a  b  c  d

-> Word inserts the row content into the first cell:
1  2  3  4  
a  b  c  d
e  f  g  h
abcdi  j  k  l

(whenever in OVERWRITE mode or not!)

Desired behavior: have an option (Paste Special?) to tell Writer *how* to *insert*

EITHER:
1  2  3  4  
a  b  c  d
e  f  g  h
abcdi  j  k  l

OR:
1  2  3  4  
a  b  c  d
e  f  g  h
a  b  c  d
i  j  k  l



Those are just some cases...

Reassigned