Still fine with
Version: 7.0.0.0.beta1+ (x64)
Build ID: 2891e91a513520d68ea2b8c59c14335861a15253
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL

Still fine with
Version: 7.2.1.0.0+ (x64) / LibreOffice Community
Build ID: 8fdbb8aed1b48734a717d5f98ada566de7204605
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL

Also in
Version: 7.3.0.0.alpha1+ (x64) / LibreOffice Community
Build ID: 7b0aabe71d2455f6f643553a07f1056935cf190f
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL

Reproducible in:

Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: 17a4f4d5e4d49189b43e748271d2d4fa330eef9b
CPU threads: 8; OS: Linux 5.11; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Bibisected to:
$ git log --format=reference 253bee65bc24d999c3629a4d503d0fa01b355cfc..3262fc5ef3bde5b158909d11ccb008161ea95519
3262fc5ef3bd (tdf#142304 a.o. Improve wrap margins in docx filters, 2021-05-15)
2ffdd3706792 (tdf#139549 DOCX import: document got modified at import time, 2021-01-16)
67a56b715915 (sw: prefix members of HTMLTableColumn, HTMLTableContext, SwWriteTableCol ..., 2021-06-28)

Whereas the following one seems related:
commit 3262fc5ef3bde5b158909d11ccb008161ea95519
Author: Regina Henschel <rb.henschel@t-online.de>
Date:   Sat May 15 23:40:34 2021 +0200

    tdf#142304 a.o. Improve wrap margins in docx filters

Adding Regina Henschel to cc: would you please take a look? Thanks.

The wrap is determined by a drawing object, which is a custom shape rectangle without fill and stroke. That is "Frame1" in the branch "Drawing objects" in Navigator.
This rectangle has a BoundRect, which is shifted up by 1 (Twips) compared with the FrameRect. You can see both with the "Development tools". There is a second object named "Frame1" in part "Shapes" in the "Object" pane in "Development tools". That is that from branch "Frames". That one from branch "Drawing objects" has "DYNAMIC" in the property "TextWrap".

Because the rectangle has no transformation and no stroke, BoundRect and FrameRect should be the same. The difference happens somewhere in opening the odt document.

MS Office puts differences between bounding rectangle (=BoundRect) and snap rectangle (=FrameRect) into the attributes wp:effectExtend in the file. Without my patch that was not done on export, with my patch LO writes them to file too. MS Office has no UI for that, but uses the values.

On import from docx the values from wp:effectExtend are incorporated into the wrap distance from text, because LO has nothing comparable to "wp:effectExtend". In this case you get a top distance, in UI 0.02mm, which extends the wrap area of the shape so that there is not enough space for the characters of the third text line.

So the problem is not directly in my patch, but the question is, why the bounding rectangle is shifted up on opening the odt-file.

Another question is, whether my patch can/should workaround the underlying problem.

I guess something is off with the file itself.

It has drawing object frame & a image frame on top of each other. Still no clue how this happened. But well DOCX export converts frames to Drawing objects. I obviously used a quite a number of master builds

So the file itself might be an anomaly

Created attachment 177215 [details]
Only Rectangle

The double "frame1" comes in with ODF -> docx -> ODF. But the problem exists with a pure rectangle too, see attachment.

Nevertheless the way an image with caption frame is exported to docx is questionable and needs improvement for better ODF -> docx -> ODF. But that would be a separate issue.

repro 7.6