Lossless JPEG rotation fails where JPEGTRAN works

The -trim option of jpegtran cuts off the remainder part.
If that kind of loss isn't wanted, there is the "patch method" described in the given post.
In this case it extends the width to the next multiple of 16, which is 4304, adding 13 pixels wide "garbage".
Here you see where the name "Minimum Coded Unit" comes from: There are always full-size MCUs coded in the image. The encoder adds the "garbage" appropriately.
Now after rotation the bottom edge is perfect, and the garbage strip appears on the top edge of the image, which looks as follows:

Usually I choose this method, because nothing is lost.
Recently I found many 1080x1079 images on Instagram.
This is a no-brainer: Patch to the common 1080x1080 size and you will hardly notice the extra garbage line.

These options seem rather inappropriate for unattended application.
That's why I called another solution which was found in the Acdsee and other image viewers thread "somewhat reasonable", in fact for unattended application. It is apparently implemented in the GDI+. Such implementation is a bit demanding for the developer, and in fact they didn't get it quite right as described.

Regards
Guido