Are you annoyed by pseudo-random breakage in Ignition project library scripting? Odd top-level constants being garbled, or operations in the top level that have side effects running twice? Or more?
Not happening much, but always around project edits, and sometimes even on gateway restart?
Yeah, me too. 
Poking around under the hood back in the spring, for a module development task, I ran across some problematic IA bytecode and pinged some people. But it went nowhere, as I could not, at that time, make a reliable reproducer.
But I dreamed some code this week, thanks to an exotic consulting task, that led to a reproducer in a nice, self-contained project. On decent multi-core hardware, the reproducer runs its script init in parallel, near-simultaneously, in five threads. On startup and on every project edit.
Import that into any gateway and immediately see the race in the logs.
I'm sure IA will fix this, but there are many, I suspect, who would benefit from a workaround in the meantime.
If you try the above project and it shows the problem, replace the script module's import section with this alternate:
# Catch racing initialization threads (See IA support ticket #131484)
import sys, threading
globals().setdefault('initLock', threading.Lock())
if not initLock.acquire(False):
# not first
with initLock:
pass
sys.exit()
# One more leaker possibility. No need to wait on this one.
# The key checked can be any of the top level variables instantiated below.
if 'logger' in globals():
initLock.release()
sys.exit()
from java.util.concurrent.atomic import AtomicInteger
And add this at the bottom of that script:
# The following must remain at the end. There *must* be error checking
# above to ensure this executes.
initLock.release()
And you should see one "Initializing" report per project edit thereafter.
Tweak to suit.
I will report when I'm told this is fixed.
{ You shouldn't expect any proper external python IDE to like that work-around, due to its use of variable names that have never received an assignment. 
}