From memory I can only answer one of those: The way I understand it (and I could be wrong), your programs theoretically should only need modifications if they have a concurrency related bug. The global interlock is designed to take a sledgehammer at “fixing” a concurrency data race. If you have a bug that the GIL fixed, you’ll need to solve that data race using a different control structure once free threading is enabled.

I know it’s kind of a vague answer, but every program that supports true concurrency will do it slightly differently. Your average script with just a few libraries may not benefit, unless a library itself uses threads. Some libraries that use native compiled components may already be able to utilize the full power of you computer even on standard Python builds because threads spawned directly in the native code are less beholden to the GIL (depending on how often they’d need to communicate with native python code)

The could be using .js and .py files directly as config files and letting the language interpreter so the heavy lifting. Just like ye olde config.php.

And yes this absolutely will allow code injection by a config admin.

Found the FF14 fan lol
The release names are hilarious

Does that still happen if you use the merge unrelated histories option? (Been a minute since I last had to use that option in git)

fail2ban isn’t a WAF?