After a little testing with $dllcall(), other things that might be useful for it:

* Some way to identify how many dllcall processes are running, and which ones they are. I know the $dllcall() parameter can include text on the commandline sent to calledalias to identify which of several dllcall() events is being returned, but there isn't a way to identify info about any dllcall processes running in the background, other than /dll -u fails if it's within a dllcall process.

* some way to safely unload a dllcall() process that can't be made to exit with /dll -u

* a bitflag variable filled during LoadDll which informs things like:
+ whether this is a $dll() or $dllcall() that's loading
+ whether this dll is already running in the background under another $dllcall()

A bitflag makes it easy to add future info without needing to fine new fields, as long as the dll knows not to assume that not-yet-defined bits would be 0's.

* Something a DLL can do during LoadDll to set a flag telling mIRC to halt the load if there's already a dllcall process running in the background, as well as being able to set a flag telling mIRC to halt this load attempt for whatever reason.

Because dllcall() is multi-thread, dll's using global variables are very likely not going to do well with having 2 processes run at the same time. So dll's might want to deny the attempt to call them using dllcall(), or to allow that if they can deny being launched as a normal dll() launch while there's a dllcall() process running in the background.

As a test, I used dllcall() to give a .dll the task of calling a subfunction 0xf0000000 times, where one thing the subfunction did was incrementing a global dll variable. When run as a dllcall() by itself, the end value of the counter increased correctly. While the dllcall() ran in the background, I ran the .dll with several dll() commands which each made 1 attempt to bump the counter, and a high percentage of the extra bumps were missing from the counter's ending value.

I then launched 2 identical dllcall() prcesses to each increase the counter by 0xf0000000. Instead of the ending value being +0x1e0000000 it was only +0x12d7b9b33, indicating the non-threadsafe usage had missed 37% of the bumps to the counter.