First, naming a batch file mklink.cmd containing a command line with just mklink is no good idea. On double clicking on this batch file it recursively executes itself in an endless loop because Windows command interpreter has to search for an application or script with name mklink with a file extension in environment variable PATHEXT in current directory and if not found there in all directories listed in environment variable PATH. So the batch file mklink.cmd executes mklink which results in executing mklink.cmd if the current directory on batch file execution is the directory of the batch file. Better would be to specify in batch file mklink with full path and file extension, i.e. %SystemRoot%\System32\mklink.exe. Best would be naming the batch file not exactly as a standard console application, for example LinkUE.cmd.

Second, there is the environment variable UEINIDIR. Adding this environment variable to user or system environment variables via Control Panel - System - Advanced system settings - tab Advanced - button Environment Variables with value D:\Google Drive\mlink\UltraEdit should make the folder linking unnecessary. (There are some exceptions because some files are always stored in %APPDATA%\IDMComp\UltraEdit.) I suggest to set environment variable UEINIDIR in your configuration on both computers in addition to link to avoid link usage for all files on which UltraEdit uses UEINIDIR.

Third, UltraEdit loads settings only once on startup of UltraEdit and saves them only once on exit of UltraEdit. So if you change a setting in configuration and close the dialog with OK the modified settings are applied by UltraEdit for running instance, but are not immediately saved into the INI file (on using INI file instead of Windows registry for settings as by default). The modified settings are stored on next exit of UltraEdit.

So if you modify a setting in configuration in UltraEdit running on computer 1, close the dialog with OK, let UltraEdit running on computer 1 and start UltraEdit on computer 2, the still unmodified INI file is read by this UltraEdit on computer 2. The last exited UltraEdit instance determines the settings for next started UltraEdit instance.

Account settings for FTP/FTPS/SFTP or SSH/Telnet are saved immediately if not saved in INI file of UltraEdit.

Please note that UltraEdit uses file access locks to prevent a read/write of the configuration files by another instance of UltraEdit when an UltraEdit instance currently reads/writes the configuration files. This is necessary for example on starting two UltraEdit instances at the same time, or exit an UltraEdit instance while another instance starts at the same time. The UltraEdit instance not yet having file access to configuration files waits silently in background until the UltraEdit instance currently accessing the configuration files closes the configuration files resulting in unlocking read/write access on the configuration files by other applications. This is necessary to prevent corruptions of the configuration files as it happened many years ago before using read/write file access locks on accessing the configuration files on using multiple instances of UltraEdit. You should take care about that as I don't know if that file access locks/unlocks work also with automatic synchronization done by Google Drive. You better backup the UltraEdit configuration from time to time. UltraEdit has a feature to backup/restore its configuration.

mklink.exe must be executed as local administrator. So I suppose you right clicked on mklink.cmd and clicked next in context menu on Run as administrator. This results in changing the current directory from directory of the batch file to directory %SystemRoot%\System32. For that reason Windows command interpreter finds first %SystemRoot%\System32\mklink.exe instead of %~dp0mklink.cmd on searching for mklink.*. So the batch file mklink.cmd works by chance, but not by design.

See also answer on Stack Overflow question: Why does 'Run as administrator' changes (sometimes) batch file's current directory?

I suppose further that the directory containing mklink.cmd is not in environment variable PATH or its directory path is in list of directory paths after %SystemRoot%\System32. It is NEVER a good idea to name a batch file identical to an executable in %SystemRoot%\System32.

See also answer on Stack Overflow question: What is the reason for '...' is not recognized as an internal or external command, operable program or batch file?