Created attachment 164131 [details]
Schematic with two tables - one with a merged row illustrating the bug.

I believe it's not that the right-side border is always missing. Rather, it's that the right-side exterior border takes on the properties of the interior vertical border. In the original attachment, the interior vertical border is specified as blank, which is why the right-side border is missing.

As a workaround, if you modify just the interior vertical border within that merged cell, you can make the right exterior vertical border to be whatever you want it to be.

Of course! Thanks, Alan. I should have thought of that -- though that is at least awkward behavior, which most users might not understand. It is also, as I mentioned, NOT the way a table in Writer behaves -- which raises the general questions:
 (a) Why are these functions (like tables) implemented differently in the different components?, and
 (b) Is it acceptable for the same features in different components to behave differently?

(Also in this context, the option "Merge adjacent line styles" does not exist in a Draw table.)

Given the work-around, I could be comfortable with calling the title bug confirmed (NEW) but of very low priority, as those more general questions are really the ones to answer (and likely DUPLICATE of others). What do you think?

My opinion FWIW is that it's plainly a bug, and shouldn't be considered merely a different way of implementing borders on Draw (vs Calc and Writer). Hence my use of the term "workaround." :-)  I would be surprised if any casual user would find the workaround intuitive, or if this was really the intended behavior of the programmer.

This being my first day using LibreOffice Bugzilla, I'm not in a position to judge priority.

Note that this bug also appears when merging cells vertically, in a column. If the bottommost cell is included in the merge, the border properties of the bottom border in the merged cell are taken from the settings for the interior horizontal border, rather than the exterior horizontal border. The top border works correctly, however.

Good catch! - and to be expected: 
horizontal merge uses outer border for left, inner border for right;
vertical merge uses outer border for top, inner border for bottom.

Confirm with
Version: 6.4.5.2
Build ID: a726b36747cf2001e06b58ad5db1aa3a9a1872d6
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3; 
Locale: ro-RO (ro_RO.UTF-8); UI-Language: en-US
Calc: threaded

In version 5.4.7 table properties changes the cells and not the table.

After that version we can reproduce this bug.

Version: 5.4.7.2 
Build ID: c838ef25c16710f8838b1faec480ebba495259d0
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk2; 
Locale: ro-RO (ro_RO.UTF-8); Calc: group


Also in
Version 3.6.7.2 (Build ID: e183d5b)

Something is strange.
This bug was solved just in 5.4.7

See the video.

Version: 5.4.7.2
Build ID: c838ef25c16710f8838b1faec480ebba495259d0
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk2; 
Locale: ro-RO (ro_RO.UTF-8); Calc: group

Created attachment 164783 [details]
video showing the bug NOT in 5.4.7 but everywhere else

Can you cite the earlier (version of this) bug?

i don't understand your request... Please refraze.

In the earliest version it is the same error. After that it is solved in 5.4.7 and the problem came back.

In comment 8 ignore this sentence: "In version 5.4.7 table properties changes the cells and not the table."

All the version are affected (except 5.4.7), so I mentioned at version Inherited from OOo. It's an exception in 5.4.7. I can not mention 5.4.7 as the beigining because oldest version are also affected.

Bogdan, in Comment 12 you said "I don't understand your request ...".

Please ignore my question from Comment 11; it was based on a misunderstanding of Comment 9: "This bug was solved just in 5.4.7"  I mistook that to refer to an earlier bug report that was fixed. Sorry for that misunderstanding, and thanks for clarifying your comments (a process that was underway before I asked).

Tested on 7.3.5.2 (x64) on Windows 10.0 Build 19044

Both column and row merges no longer seem to break exterior border settings

Agreed: merges no longer break the exterior border (that is, transfer the interior lack of border to the exterior), but at a curious cost. I've been trying to figure out the connection, and finally decided that I will have to just describe it, and hope someone else sees the connection.

Make a simple 3x3 table, with contents --
 A1 B1 C1
 A2 B2 C2
 A3 B3 C3
-- and put border around the outside, but no borders between columns or rows. This is enough to test most merge situations, and all seem to behave properly and Undo properly.

Now make the 3x4 table a 4x3 table by Insert|Column|After --
 A1 B1 C1 D1
 A2 B2 C2 D2
 A3 B3 C3 D3
-- and the first strange thing happens: the outside border copies to the inside, between columns C and D. 

But it's not just Insert|Column|After. Insert|Column|Before gives this --
 A1 B1    C1
 A2 B2    C2
 A3 B3    C3
or (depending on whether a cell or column is pre-selected) this --
    A1 B1 C1
    A2 B2 C2
    A3 B3 C3
-- which also copies the outside border to the inside. 

As with columns, similar things happen with rows when you go to a 4x4 table, but I won't belabor the point further with examples. Moreover, properties of cell text contents are not maintained to the new row or column - again, I won't lengthen this further with examples.

All of these behaviors can be worked around, but are clearly buggy if one expects tables in Draw to behave as in Writer or other LO components -- which begs the obvious question: in an integrated office suite, should not tables use the same code across components? The basic problem may be that a table is a "Shape" in Draw -- as opposed to, say, a functional table in a frame or box.

So this bug may be considered superficially "FIXED" -- but on code that will raise new problems. On that basis, I'm changing Status from "RESOLVED-FIXED" to "REOPENED" until dev can consider this comment. Maybe that's the best we can do for now?