Now that CPython has a definitive roadmap for removing the global interpreter lock (GIL) and supporting true multi-threading, i.e., free-threading, (https://peps.python.org/pep-0703/); Esri should start to lay out its roadmap to support free-threading with ArcPy. Supporting free-threading is no small undertaking for a package like ArcPy, but it all starts with a plan and taking steps to implement the plan. Many scientific computing Python packages are already releasing versions that support free-threading (https://py-free-threading.github.io/tracking/).
Supporting multi-/free-threading is crucial for ArPy. Although ArcPy can be run using Python's multiprocessing module, there are significant performance reductions and some functional limitations that come with running code in other processes versus other threads within the same process. Although I have forced ArcPy into multi-threading, it is clear that some functions, methods, and geoprocessing tools work fine while others get corrupted very easily.
