Passing my_perl on the stack/register is alot faster than the GLR and SLR and TlsGetValue calls.

Ignoring that I don't know what "GLR and SLR" are -- and you do not bother to explain them -- I'd be interested to see proof of that "much faster". Faster I have no doubts, but much faster?

See "TlsGetValue was implemented with speed as the primary goal."

And I counter that assertion with: speed isn't everything.

Burdening every function, and every programmer, with the need to accommodate a 'pass-through variable' and relying upon the optimiser to make it disappear when not required -- all to save what effectively becomes something like mov rax, GS:[8*rcx+0x2c] -- is short-sighted in the extreme.

And wrapping it over in a bunch of "trick" macros make the programmer burden -- via cognitive disconnection -- even worse.

I took the OP to mean...

How would you handle ...

I wouldn't. Just because I took the OP to mean that; doesn't mean that I think that it is a good idea, or even possible.

I only attempted to answer -- at perhaps a superficial level -- the OPs question: "I'm curious why non-threaded perl can do what thread perl can't do.". Naught more.

Which is why I think your post would have been better directed at the alternative you suggested.

GObject and Perl's GC systems have many similarities. ... I am saying that would be a bad choice.

Then why mention it? No one else did.

Aren't you just as guilty of misdirection by bringing it up and leaving it hanging as the guy that suggested: "you'll be fine so long as you don't use threads"? Which seems to be the focus of your posts.