Automatize creating, moving and resizing a persistent data partition in a dual boot scenario

I used to add the --move-data parameter ...

This seems likely to be your problem. Partitioning tools operate on the partition tables only. They generally don't touch the underlying data on the disk, with the exception being sfdisk when using the --move-data flag.

Unless you pass --move-data, the old data won't follow the new partition table. This effectively results in an incorrect partition table because the data is still in the old location. In a data recovery scenario, you'd want to rewrite the partition table again to match the old start & end locations for each data partition. (Unless anything else already overwrote them, you can generally recover data from a disk this way.)

Unless the new partitions are created in free unused disk space, data loss is always a possibility when using tools such as sfdisk, sgdisk, gdisk, and even older tools like fdisk, parted, gparted, etc...

Note that the term "data loss" in this case doesn't mean that you've corrupted the underlying data, but rather that you've lost easy access to it because the partition table entries now point to different locations. When the system tries to read filesystem data at those new sector offset locations, it appears corrupt because it's not starting at that point. A metaphor might be that you lost the table of contents for a book's chapters & starting pages, then tried to create a new table of contents so you could insert your own chapter but forgot to actually move the other chapters and page numbers. Then if you started reading according to the newly incorrect ToC, you'd likely end up starting in the middle of a chapter and the book wouldn't make chronological sense.

I'd suggest tracking down why your original error occurred:

sfdisk: /dev/mmcblk0p4: failed to move data: Not a directory

It's likely that this original error message is happening for another reason, which is hard to say why without seeing your script code or digging deeper into what's going on in the system running the command. My first guess is that if this is happening on boot this could be due to the /dev/mmcblk0p4 device file not actually existing yet due to race conditions common with SystemD and system startup in general. If that's the case, ensure that your script is running after the /dev/mmcblk0p4 device is created and ready. If you're using SystemD, it's as simple as waiting until the dev-mmcblk0p4.device unit is ready. Just add a dependency on dev-mmcblk0p4.device for your startup script. If you're chaining other .service files together as dependencies of each other, make sure you are using systemd-notify as a post-command (or sd_notify() for compiled programs) to signal when each service step is completed. A simple Wants=, Before= or After= unit dependency can still suffer from race conditions because SystemD tries to launch everything in parallel as fast as it can without regard to whether those other units actually completed all their work.