Hint: Temporary workaround I started to use: Manually create in each workspace symbolic links for the files needed during execution in the @script directory pointing to the file in the directory with the random name.

My organization's problem with the random directory name is primarily the length of the name. Our controller cannot do a lightweight checkout of the repo so it creates non lightweight checkout on the controller and then runs the job on a node. But since our controller runs on Windows and the hash directory is 65 chars long we hit the maximum path length in Windows and cannot complete the checkout. (Large repo with several layers of directories.)

I guess we can do a workaround and skip checking out via Jenkins git and do it by script/build step, but it doesn't really feel right...

My workaround: when using a declarative pipeline instead of a scripted pipeline, Jenkins will also checkout the script repo into your workspace. This way, the auto generated sub dir can be ignored. So you can just import your libs using:

def myVar = load "./<path_to_script>";

Instead of:

def rootDir = pwd();
def myVar = load "${rootDir}@script/<path_to_script>";

the length of the name. Our controller cannot do a lightweight checkout of the repo

Sounds like JENKINS-67836.

See this comment for discussion of some supported alternatives if the related changes break your use case.

See JENKINS-67836 if the length of the directory names is causing issues for you.