FYI, here is below how I proceeded (and came with some questions along the way).
I decided not to map the librelec disk image but rather restore the librelec partitions on part 2 and 3 while using G4D on part1.
-Created part 1 (active / fat32) 64 mb for grub4dos
-Created part 2 512 mb for SYSTEM
-Created part 3 32 mb for STORAGE
-Restored SYSTEM.IMG (from librelec.img) to part 2 (which has a default VOLNAME/LABEL="LIBREELEC FAT16" which needs to be changed)
-Restored STORAGE.IMG (from librelec.img) to part 3 (which has a default VOLNAME/LABEL="STORAGE")
That approach sounded quite straight forward to me.
Then booted onto this new disk to discover that Grub4DOS (0.4.6a, tried different versions) would not recognize the FS on part 2.
Note that this part 2 is seen without any issue under windows.
Looking closer at, it is a FAT16 FS with OEMID=SYSLINUX.
I tweaked a few fields in the MBR (part type=06/0E) and in the BS like OEMID, media description, hidden sec but would not succeed.
I then recreated part 2 (and formated to FAT32 under windows) and this time, copied files from SYSTEM.IMG to this new "windows fat32" part 2 and modified the BS volume label to SYSTEM.
Note that this "copy" approach is possibly linking to the "copy" approach which Alacran ultimately used.
This time Libreelec would boot just fine with the below grub4dos config:
default 0 PROMPT 0 title run find --set-root /syslinux.cfg kernel /KERNEL boot=LABEL=SYSTEM disk=LABEL=STORAGE tty portable quiet boot
Any idea why Grub4dos would not recognize the FS coming from the FAT16 image used by librelec?
And (beyond the now well understood matching volume/boot sector UUID or LABEL prereq), would not this be the main blocker for Grub4dos to use "as is" the image provided by Librelec?
Below the original Libreelec FAT16 part which Grub4dos would not recognize.