The problem with just "sending" a message to the main thread is, what if the main thread is in a blocking syscall, directly from Perl lang or through some XS-ed C library? How do you ensure the responsiveness of the fake-signal if the main thread is blocked in the kernel?
I did once take a C debugger, when the console event hit the 2nd thread, I paused the main thread, let the 2nd thread run to completion and shut down Perl interp struct, and I dont remember (and cant research it ATM, normally I would research it for you but im not at my devel machine this post is from memory), but I think the 2nd thread ended the 2nd thread, I then ran the 1st main thread, now with an almost uninitialized interp struct, and it very quickly called C's exit() and that was it. I also fixed a race condition maybe a year ago between sending a kill 9 from a parent fork thread/fake process to the child fork thread/fake process, where the child thread was still initializing itself in user mode kernel32/ntdll, before calling any process specific code, and when killing the child thread, it would leave the DLL loader lock, locked, by the now gone 2nd thread, when the perl interp trys to exit, the DLL loader from the main thread tried to aquire the DLL loader lock and hung forever.
I've also dispatched events from multi threaded pure C code, using Perl's win32 fake signals dispatch code by setting a 1 in some array in the perl interp struct which corresponds to one of the 2 dozen signals names on Win32 perl, then setting a global flag that there is a pending signal for the interp to dispatch to the perl lang level, and on PERL_ASYNC_CHECK() the fake signal was dispatched, which eventually called a Perl lang sig handler which then called XS code which pulled events off the pure C's event queue. I think I used signal NUM05.
You should ask on the p5p mailing list. You will get more C/interp internal knowledgeable eyes than on PerlMonks. The p5p IRC room has less eyes and less Win32 eyes. Since there arent very many p5p win32 guys. You probably want an answer from steve hay, tony cook, or jan dubois. None of them are active at PM. Also use git blame, for example http://perl5.git.perl.org/perl.git/blame/HEAD:/win32/win32.c
and look at the evolution of the code you are wondering about.