I see some of your menus (e.g. UEFI-vhds.lst) assume that the USB boot drive is hd0.
With UEFI this cannot be assumed. Unlike MBR\Legacy grub4dos/grub2 etc. the boot drive is often not hd0 - it can be hd4 or hd1 or anything.
hd0 under UEFI could be the users main system hard disk!
It seems to me in this case Ventoy takes care to make the boot device hd0, and in turn runs ventoy_grub.cfg when selected, and from it, it's loaded bootia32_g4d.efi or bootx64_g4d.efi, from $vtoy_efi_part that is in the second partition (hd0, msdos2), then the G4E menu.lst when loaded is in (hd0,1), and it seachs for the secondary UEFI menu files in (hd0,0), and if found makes root (just to make sure) where is located /Ventoy.tag [first partition of USB device or (hd0,0)], before chainload to the secondary menus. So I think the potential issue you mentioned is avoided. Don't you think?
I decided to use tag files to avoid this issue, as I also have into my internal HD G4E and MBR menus, with same names in some cases, from my previous tests, and also same apply for VHDs.
P.S. Just in case you didn't know. Another internal variable is @uefi
so under grub4dos, @uefi is not set, but under grub4efi64 it is set to 64 and under grub4efi32 it is set to 32
So you can use the same menu.lst file for all boot environments by checking this variable
I didn't know this variable.
In fact my first idea was to unify as much as possible the secondary menus, but it is not very practical in this case as in MBR G4D commands for Wimboot VHDs from a USB device, require to be mapped as (hd-1) not as (hd), as it is mentioned in the comments in vhds-USB.lst
And in G4E no matter if internal HD or USB device they are always mapped as (hd), so to avoid users confusion and also trying to make things as much clear as possible for non advanced users, I took the decision to keep the secondary menus separated.
I appreciate a lot your comments, and you can be sure I will run some test to make me more familiar with them, and I will evaluate again the idea of unify the menus, as long as the commands don't result very complicated for non advanced users, as in the end the main idea of make public this project is induce other users, especially non advanced users to start experimenting, as that's the way I have learned all the few I know now.
I still remember when started using RmPrepUSB, it was a great experience for me, so much I was voluntary to make Spanish translation, you were my teacher in MBR grub4dos, so I have a big respect for you and all your knowledge in the subject.
Same happenned also with WinNTSetup, it that case I asked JFX if it was possible to translate it to Spanish, to make it more accessible for people that don't speak English, he was agree, and mine was the first translation to other lang.
I also made the Spanish translations for Wimlib-clc, ImDisk Toolkit and Ventoy, with the idea that all this Great tools that took so much effort to the developers, and are free shared, deserve to be Universaly used and recognized.
So again thaks for your disinterested advice.