Cannot run multiple guest VMs of the same type if their *.vbox files are all in the same directory

[Kumba]

It seems that Virtualbox is using some kind of folder-level locking construct that makes it impossible to run multiple guest VMs if those guest VMs' corresponding *.vbox files are all in the same folder. Attempting to launch a second VM stored in the same folder when another is running will lock up the window before the BIOS image appears and the VM will crash with this error:

The VM session was aborted.
Result Code:
E_FAIL (0X80004005)
Component:
SessionMachine
Interface:
ISession {c0447716-ff5a-4795-b57a-ecd5fffa18a4}

I like organizing all of my guest OSes by their main OS-type. So, for example, Windows NT, 2000, 2003, and 2019 will all live in the same "WINDOWS" folder under a given directory hierarchy. Ditto for Solaris 10, Solaris 11.4, OmniOS, and OpenIndiana under a "SOLARIS" directory. I do not like using individual subfolders under this hierarchy and I want all of the *.vbox files to be together.

I don't really know why I like it this way, but I do, and I have found it difficult to organize things in a different manner that makes both myself and Virtualbox happy. It feels like the folder-level locking is a kludge (I mean, why not file-level locking?), or at least, the crash is not being handled terribly well (a helpful error message being returned would be a marked improvement vs just outright crashing).

FWIW, how I got to this condition is every time I create a new guest VM, I set the bare minimum config, then shut VBox down and any services to make sure all of the XML files are flushed out. Then I manually move *.vbox and *.vdi files around to where I want them, then edit the XML's to point things to the new locations. Other than the occasional hiccup from a still-running VBox process holding a lock, this setup has worked well for the past several years. The inability to run multiple OSes of the same type is not a major blocker, but I had been perplexed for a while why it wasn't possible until I finally did some debugging.

Can someone maybe take a look at whether folder-level locking is still appropriate, or at least put some code in to detect this scenario and return an error message to the user?