I have to, because this API is the only official way on a Win-OS, to create - well - a thread.
Any language who wants to establish an STA (on a new thread), has to call this API at some point.
Not only CreateThread.

And no - FreeThreading (in the real sense) implies also cross-thread-sharing of (global) variables -
which I did not try to attempt (by hacking VB6 with regards to avoiding the built-in ThreadLocalStorage).
In your opinion, if we do not use global variables, then this turns out to be a non-free-threading? But free-threading means you can safe call the methods without marshaling across threads. The second question - who hacking TLS?

You mean implicitely - via DoEvents (and its "hidden Sleep(0) call")?

Well, I've found - when developing/testing the (threaded) RPCserver-support in RC5 (decades ago) -
that a final Sleep(0) call in the "pump-loop" was increasing performance under heavy concurrent load.

So please read, what the MSDN has to say (about Sleep with Param 0) -
or alternatively this discussion: https://stackoverflow.com/questions/...ance-of-sleep0
I mean there is much suitable way by using special Wait functions (like WaitForSingleObject).

I've never said, that *everything* in your threading-modules was "a hack".

And in case you meant, I've "stolen something" - well, I didn't.
In the new Demo, I've restricted myself to "only the things which are known to be safe to use"
(especially when the whole STA-establishing stuff is encapsulated in a Dll, as in my example).
No-no. You (and others) can use my codes even don't mention me (i always told it). This isn't problem. I meant other. When i told you - "an user should know it" you answered "A VB6 beginner (or hobbyist) does not need to know (in detail) what an STA is, or how TLS works (underneath)."
If you would demonstrate the Mandelbrot example at the first post i didn't begin this discussion about learning because it would have no sense. Just what i told about you've implemented in the new example which is very good and useful. Just imagine if your first post was with this example do my following post have sense?

I said, that the "interna of STAs" are not, what a User (of an STA-threaded solution) should "bother with".
What's the internal? I already wrote about that (MessagePump, Marshaling, etc.). This sounds very strange you made the example with that internal things and you told user shouldn't bother about that. How should an user go steps to StdEXE+DLL from AxEXE without that things?

They are (black-box-like) hidden when the builtin AxExe-threading is used -
and they are "hidden in a Dll-binary", when StdExes want to use the same STA-based threading
(as shown in my example, or when using DirectCOM.dll from the RC5-package).
Again . They aren't hidden in your example. When you need to perform an async task (the multithreadin is used for) you use this things and you need to know that things to avoid the typical threading errors like deadlocks, etc.