So, you could have 100 threads and there would only ever be 1 copy of the vfp runtime in memory.
Help me here. Maybe I wrongly confusing thread with clients?
Are their situations where a MTDLL would be less efficient than a STDLL or an EXE COM?

Would a VFP foxISAPI MTDLL have any advantage over an STDLL or EXE COM. With this configuration its a quick (HTTP) in and out. But, two clients (or more) clients could be requesting SERVER around the same time. Would a benefit of a VFP MTDLL foxISAPI be that the clients would share/resuse the VFP runtime in memeory, whereas a STDLL or EXE COM would load and the release VFP runtime?

In my experience, Apartment model threading is a very efficient and fast way to service multiple threads - it's just not as effcient as .NET's model(mostly because of the thread-switching of the apartment model).
What is "thread switching"? Could you share a simple example of a service where this feature would be an advantage?

Is there something I probably do all the time in my projects that a "thread switching" feature might make better?

MTDLL would really be cool if threads or clients passing through could have a shared cach memory that they could read or write to.IOW - instanciation would not reset. In/out foxISAPI HTTP servers, for example, using DBF stores, have to OPEN the DBFs. It would be nice to have a CACHE in a MTDLL that was shared, and nver destroyed unless intentionally reset. Re-Creating the handles eats up all the clock.

Many of the older 3rd party web tools are built on this technology, mostly because they began before vfp mtdll technology was introduced.
And of course many of the vendors of those tools were always telling us, "... sony, the problem with MTDLL is you can't reset it without having to shut every thing down .. by cracky!" Air planes would never have happened if Wilbur's mother had been out there twisting his ear while warning that he might break his neck (by cracky). But such are these times.