How to re-take existing photos? (Exact coordinates cannot be entered. Gimbal yaw differs from aircraft yaw.)

Background: I have Elite plan and use a DJI Mavic 2 Pro.

Goal: My goal is to take the same set of pictures every once in a while (e.g. four times a year) to discover changes in landscape, mainly vegetation. I have chosen a set of reference pictures from those taken in the last years with the same drone model and now would like to create a mission in DL that (re-)takes exactly these pictures.

In trying to do so, I ran into multiple problems:

1. DL has no feature to re-create an existing photo.
I am quite a bit deceived that DL does not seem to offer any way to import settings from an existing image. Or have I overlooked something?

As there is no tailored feature for that, I went over to recreate it with the photo component by manually entering the values derived from the XMP meta data of the reference pictures.

2. DL does not accept manually entered exact coordinates
Unfortunately, it doesn't seem possible to enter exact coordinates for the location of the aircraft during the photo.
a) To begin with, the first problem is, that if you are too slow to enter Lat and Lng at the same time, it behaves very weird. It seems as it resets the other (not edited) coordinate. This is not a matter of too much distance from the previous location, as the old and new points are just a couple of metres away from each other.
b) Even if I manage to input the coordinates fast enough, the second problem comes into place: The coordinates are automatically rewritten to some place nearby.
Example: I enter 49.501234 and 14.461234 (really fast pasting, before automatic value check/update), but it is rewritten to 49.500842 and 14.462642 after two seconds.
Both these things are just faulty behaviour of DL. There is no message what is happening, (non-existing) docs say nothing about this. I also tried with different decimal lengths and with different desimal separators, all without luck. It must be a bug.

3. Gimbal yaw does not equal aircraft yaw
The reference pictures have values of "GimbalYawDegree" and "FlightYawDegree" (I assume the latter to be aircraft yaw). I guess this is due to the gimbal mitigating aircraft position, even when the gimbal is "fixed" (i.e. not manually yaw-able), and it happens even when the aircraft is just hovering (e.g. due to a tiny bit of wind). On some pictures the values differ just by 0.2° or 0.5°, but I have also a reference picture where gimbal yaw is -152.80° and aircraft yaw is -140.20°. In any case, I set the gimbal yaw value as heading in DL. (Of course converted to usual 0°-360° heading reference, i.e. -152.80° results in a heading of 207.20°, thus entering 207° in DL, which allows no decimals here.
I took three reference pictures with these settings, but the yaw clearly differs on each picture (not only compared to the reference, but also the three test pictures taken within about 10 minutes from each other). Aircraft/gimbal yaw is as follows for this test:

Aircraft / gimbal yaw
-152.60 / -156.00
-153.10 / -155.50
-152.80 / -158.40
Target was: -153.00 (= 207° heading)

It's not that much difference in numbers, but just these few degrees make the resulting pictures quite different, which is exactly what I wanted to avoid by flying a predefined automatic mission instead of manually operating the flight.
The aircraft is completely hovering still while taking the picture, and as I also tried to use the start component of the photo component to already yaw and pitch to the same numbers as for the photo itself when approaching the destination location and set a 4s destination time, there is no movements in the seconds before. There was also nearly no perceivable wind during the test today.

Does anyone have any ideas on how to mitigate or approach this problem?
I understand this is only partly a problem of DL, though DL would presumably have the live data to mitigate this.

Conclusion
It is far more difficult than expected to achieve this (in my eyes very simple) task with DL.
Happy to hear your suggestions (and hopefully willingness to fix above-mentioned coordinate bug).

Daniel