Seems to be covered by <u>https://issues.apache.org/ooo/show_bug.cgi?id=2131</u>

NOT reproducible with "AOO 4.2.0-Dev – German UI / German locale [AOO420m1(Build:9800)  -   Rev. 1595858 2014-05-20 1]" on German WIN7 Home Premium (64bit)", “historic” 4. User Profile used for all predecessor versions.

My test: 
1. New Writer document from AOO start Center -> Insert 2 columns x 3 rows table
2. Merge the 2 cells of each row, row by row
   > Table will look like a 1 column table
3. Click into second row
   > Caret flashes
4. Menu 'Table -> Insert -> Rows - quantity=1, option = after [ok]'
   > Row inserted looks like "single column"

@vijayzither
Thank you for your feedback – unfortunately important information we will 
need to reproduce your problem is missing.
Please add all information requested in following:
a) Write a meaningful Summary describing exactly what the problem is
   (" Inserting rows in meged cells" is not the description of a problem)
b) Attach a sample document (not only screenshot) or refer to an existing 
   sample document in an other Bug with a link; to attach a file to this 
   bug report, just click on "Add an attachment" right on this page.
   If you want to attach a test kit with multiple documents zip them into
   a single testkit.zip and attach the  testkit.zip
c) Contribute a document related step by step instruction containing every 
   key press and every mouse click how to reproduce your problem 
e) if possible contribute an instruction how to create a sample document 
   from the scratch
   best way is to contribute a sample document where the first table
   is the source table and by copy/paste of the source table you 
   add a new table below where you do edits for step 1 and and by copy/paste
   of this table you add a new table below where ...
f) add information 
   f1) what EXACTLY is unexpected. 
   f2) and WHY do you believe it's unexpected (cite Help or Documentation!)
   f5) concerning your AOO version (with Build/revision ID if it's not a 
      public release) and localization (UI language, Locale setting)
   f6) AOO settings that might be related to your problems 
   f7) how you launch AOO and how you opened the sample document
   f9) Whether that worked in former OOO / AOO Versions 
   f10) whether (and how) a competitor's software (MSO, LibreOffice, ...)
        fulfills your needs

Please do not cite these hints in your reply, but cite the items like:
f7): Desktop-icon for soffice.exe / AOO File menu -> Open

Damned, may be I should have read the Product ...

Created attachment 83435 [details]
Sample Document

Reproducible with "AOO 4.2.0-Dev – German UI / German locale [AOO420m1(Build:9800)  -   Rev. 1595858 2014-05-20 1]" on German WIN7 Home Premium (64bit)", “historic” 4. User Profile used for all predecessor versions

If you have rows 1-4 with merged cells for column-cells B:C in each row 
if you click intl second row
and insert a row
the newly inserted row will show unmerged cells

More intuitive description and sample cell ranges in sample document

I think there is no defect. Simple reason: How should it work if cells over more than one row are merged? What should be happen if there are merged cells between row n and n+1 and between n+1 and n+2? And so on. Same for columns.

A change of behaviour if only one row is affected breaks consistency.

(a) Not only 'insert -> row' affected, same problem with 'insert -> column' 
    for vertically merged cells
(b) Not a new problem, already reproducible with OOo 2.0.2
(c) users might expect that merge should be respected because normally insert row
    applies format of row above to newly created row. For example document:
    before you test in Step 1 table apply green background and red characters
    to B22. If you afterwards click to B23 and insert new row, the "new B23" will
    have background and character color from B22, but not "merged"


Needhelp
-----------
(d) but is that "merge" really a format property of a cell? I am not sure, and
    Gnumeric, Kingsoft  and SoftMaker FreeOffice behave the same way.
(e) So I only can confirm the effect, but I do not know whether it's a bug
(f) I can't see the relation to Bug 2131 (Bug 8302) as in Comment 1
(g) I can't understand comment 5

Hint 1: (for only one new row)
Select a formatted row, select the paintbrush, click onto the first cell of the new row.

Hint 2: (for not only one new row)
1. Select a formatted row.
2. Copy it into the clipboard.
3. Select the new rows.
4. Edit → Paste Special: deselect all and select only [x]Formats.

I think it's at least unintuitive that Calc behaves different from Writer. Without very good reasons that would be a bug.

(In reply to mroe from comment #7)
Thank you for explication, I will think about that tomorrow

(In reply to Rainer Bielefeld from comment #8)
> I think it's at least unintuitive that Calc behaves different from Writer.
> Without very good reasons that would be a bug.

The reason is: Writer is word processing, Calc is calculation.

A text table isn't a spreadsheet.

In Calc: Merging of cells: the first cell grows to the size of the merged cells and overlap them. (The other cells still exists under this cell.)You cannot split a single cell. The fixed structure of rows and columns doesn't change. 

In Writer: Merging of cells destroys the former cells to one cell. You can split a single cell to new cells. So every row/ column can have its own structure.