Temp Lua Savestates Overwriting Each Other with Multiple VBA-RR Instances

[hypercoyote]

What steps will reproduce the problem?

1. Make multiple copies of VBA-RR's entire folder
2. Run VBA-RR from each folder simultaneously, creating multiple running instances of VBA-RR (each instance from a single folder location)
3. Load a Lua script that rapidly creates and loads savestates from each instance
4. Start the Lua script for each instance in succession

What is the expected output? What do you see instead?
Each instance should maintain its own savegame (battery) and savestate data. However, sometimes one instance will load the savestate data of another instance, thus overwriting the savegame data in memory and thus in the battery when saved within the game.

What version of the product are you using? On what operating system?
v23.6 svn480 on Windows 10

Please provide any additional information below.
I made 4 copies of the VBA-RR program and its entire folder structure. Each copy has its own lua folder with its own copy of scripts. I am using the scripts to run a bruteforce on Pokemon in those multiple VBA-RR instances. Each script creates a temp savestate file in the same folder the lua script is running from, so that's why I made completely separate copies of VBA-RR and its scripts for each instance.

However, what I've found using ProcMon is lua is also creating a temp savestate in %temp% for each instance and it is using a simple naming scheme for the temp files like snluaxx where xx is a two digit number. What can happen (and is happening) is when I start the script on two or more instances in quick succession, they may try to use the same filename and it causes one instance to load the savestate of another instance, thus overwriting the savegame of one instance.

I suggest that lua create a temporary savestate files using a more unique naming structure, such as a random 10 digit string or something to reduce the possibility of multiple instances using the same filename.

Further, I'm surprised I'm able to do this because I would've assumed the program would query to see if the file existed first. When I say that I start the script on the instances in succession, there is maybe half a second or a second between me starting each one, but I would've assumed that would be plenty of time for the program to see that another instance had created the file it wanted to use. So there may also be something that could be changed in that routine as well.