Comment copied over from
The problem appears to stem from the fact that load will actually give everything an autogenerated class name (i.e., Script1, Script2, etc). This is because load doesn't actually parse/compile the file passed to it directly - it reads that file (so, in this case, src/org/foo/devops/Utility.groovy), and parses it directly, autogenerating the class name. But when there's a package, things get...confused. The resulting loadedScripts key in CpsFlowExecution ends up as org.foo.devops.Script1, rather than Script1. Which is fine? I guess? Well, until we try to resume. Then, when we get to CpsFlowExecution#parseScript(), we end up trying to CpsGroovyShell#parse(new GroovyCodeSource("code from Utility.groovy", "org.foo.devops.Script1", DEFAULT_CODE_BASE)), and that confuses Groovy's parsing logic: if you tell it "here's a class name including package to parse, and here's the text to parse", it's going to get very confused when there's no class Script1 inside that text. So it ends up deciding the fully qualified class name is "(package).(package but with periods replaced by underscores)" for...reasons? And that results in duplicate class names and everything blows up.
So for the moment? Don't put package ... in Groovy files you're going to load. It will break things. Obviously. I think the fix for this is to just put getClass().getSimpleName() in as the key in CpsFlowExecution#loadedScripts rather than the current getClass().getName() - this definitely fixes this problem but I'm a bit wary as to whether there could be side effects. And regardless of that fix, I would not be at all surprised if there were other weird edge cases around load and packages, so...just don't do that.