I may not be able to help solve the problem, but I can at least explain a likely cause.
The mount point folders in /Volumes are created by the macOS automatic mount mechanism when it detects an unmounted volume on an attached device. After the mount point folder is created, the external volume is mounted at that folder.
If there is no other mounted volume with the same name, then the folder name created in /Volumes matches the volume name, e.g. "External SSD". If a folder of that name already exists in /Volumes (usually implying another volume of the same name is already mounted) then the folder name in /Volumes has a sequence number appended to it, e.g. "External SSD 1", "External SSD 2", etc. depending on how many are already there. This modified name is used internally as part of the unique path to the volume, it does not appear in Finder (which has no problem showing multiple mounted volumes with the same name).
After the volume is unmounted (e.g. ejected by the user in Finder, or the system shuts down), the folder in /Volumes is removed.
There are two problems that can arise with this mechanism which can lead to unexpected changes in the name of the mount point folder.
1. Sometimes when a volume is unmounted, a race condition occurs and an application manages to create a file in the the mount point folder even though the volume is no longer mounted. These files get stored in the mount point folder on the startup volume, which then cannot be removed by the system because it is not empty, leaving a persistent folder in /Volumes. This forces a persistent name change (adding a sequence number) for subsequent mounts of the volume.
2. Sometimes the system may fail to remove the mount point folder even though it is empty. This might happen due to an abnormal restart or shut down, or a bug in macOS, or a race condition between the shutdown sequence and termination of an application which is using the volume.
In your case, problem 2 seems more likely, because the problem is not persistent.
I haven't seen problem 1 for many years and macOS versions - I think it was mostly eliminated when Apple added the "trying to eject" alert which gives up when an application doesn't close a file on the external volume before the timeout expires.
You might be able to stop your problem occurring: do you normally have VMware Fusion running at the point you shut down or restart your Mac? If so, try quitting VMware Fusion first, then shutting down or restarting.
An underlying issue is that applications which store pathnames to locate a file or folder are vulnerable to name changes if the path refers to anything outside the startup volume. This includes symbolic links, which are just a pathname to the target item.
macOS aliases are a more robust mechanism as they have additional methods of locating the file or folder, including a unique identifier for an external volume, which allows them to ignore a name change of the mount point.
Given the evidence, it seems that VMware Fusion is storing pathnames (or symbolic links) to locate its VMs, rather than aliases.
