> I guess that the intent of dynamically created GIL is to reduce the "overhead" of the GIL when 100% of the code is run in single thread.

I'm not sure it is ok to guess here.  The original code was written in 1992, when system threading APIs were buggy and not always available.  Also the original GIL logic released the lock every N opcodes, which is a fragile heuristic.  The current GIL shouldn't have any visible performance cost in single-threaded mode, and in even in multi-threaded mode it's been a long time since anyone complained about a real-world performance degradation due to the GIL's overhead.

Perhaps Guido remembers the original rationale?

> This bug was reported once in 2014, then Marcin Kasperski asked for an update last month: 3 years later. It's not a common bug impacting many users.

From a maintenance POV, initializing the GIL eagerly also makes maintenance easier for us, instead of making all those dynamic checks.