What you have to understand, first and foremost, is that GNU/Linux is not Microsoft Windows, and was also never meant to mimic Windows ─ it’s a UNIX system, and its intent has always been to be an alternative to proprietary UNIX systems, e.g. IBM AIX, SCO Unix, SGI IRIX, HP/UX, et al. Therefore, if you approach GNU/Linux as a Windows-like system ─ as you appear to be doing, given your mention of drive letters ─ then you are going to run into a couple of strange surprises.
GNU/Linux is a UNIX operating system, and therefore its filesystems use and store POSIX file ownership and permissions. Microsoft Windows is not compatible with those, and the Windows NTFS filesystem does not store POSIX ownership and permissions on-disk.
This means that when an NTFS filesystem is mounted into the UNIX directory hierarchy, POSIX ownership and permissions must be faked in the kernel’s virtual filesystem layer. They are applied to the entire filesystem at mount time, and they cannot be altered on a per-file basis. They are also not stored when the filesystem is unmounted again.
Now, there are two ways through which a filesystem can get mounted in GNU/Linux. The first way is through a static record for the filesystem in /etc/fstab. The second way is on-the-fly, by the plug & play functionality of the device manager ─ more specifically, by the udisks subsystem of systemd.
And given that this is an on-the-fly mount, the permissions may not always be consistent. This ties in with the fact that in Microsoft Windows, a file is executable if its name ends in a certain three-letter suffix ─ e.g. .exe ─ which is a legacy from the days of MS-DOS and CP/M, two single-user, single-tasking operating systems for standalone computers without a network connection.
UNIX on the other hand was designed from the ground up as a multiuser platform, and in UNIX, whether a file is regarded as executable or not depends on the POSIX permissions of the file ─ there are three main permissions, read , write and execute, and three groups of such permissions, i.e. for the owner of the file, for the group that owns the file, and for all others.
Combining this with the ad-hoc mounting by udisks, those permissions are faked at mount time, and are not guaranteed to remain consistent across multiple mounts, among other things due to system updates that introduce revised security policies, et al.
And quite often ─ not always but often ─ the automatic mounting of an NTFS filesystem by way of udisks will for security reasons not set an execute permission for the files on the NTFS filesystem, given that it is after all an alien filesystem, and that any executables residing thereon could potentially undermine the stability of the operating system.
So, long story short, when your games are installed on NTFS, then they probably don’t have execute permission, whereas when they are stored on your Linux-native filesystem ─ I presume it’s ext4, which is the default in Manjaro ─ they do have execute permission, even if only because the permissions and ownership are physically stored on the filesystem.
