1) The Process DSL steps fail at creating top-level (not in folder) items, if the deployer job itself is located inside a folder.
Example: I have a `/folder` folder in my root jobs directory, and a `/folder/deployer` job in it that creates a `/free` job. When there is no `/free`, the DSL pass finishes fine. When `/free` is already deployed via `/folder/deployer` though, redeployment will fail with `ERROR: Could not create item folder, item is already managed by seed job folder/deployer`.

Looking at `JenkinsJobManagement.java:createOrUpdateConfig`, it happens because the `seedJobName` at line 146 contains the result of `getName()` — a mere `deployer`. In the `getGeneratedJobMap()` however, the seed job is stored as fully-qualified `folder/deployer`. Thus, `seedJobName != existingSeedJobName`, which causes exception.

At first glance, the bug can be fixed by simply changing `String seedJobName` from `getName()` to `getFullName()`

2) Suppose I have two jobs that both try to create a `folder/free` job: `deployer_a` and `deployer_b`. If I run them both, they will both happily easily override each other's results, even if you specify `Fail if seed collision`.

Looking at the same source file, it happens because of `getGeneratedJobMap().get(jobName)` — with `jobName` containing a mere free due to `FilenameUtils.getName(path)` above. While there is `folder/free` entry in generated map, there is no `free` entry, so `.get()` will return null and the seeder equality check will not perform at all.

Contrary, if I use `deployer_root` to create `/free` and then `deployer_folder` to create `folder/free`, then `deployer_folder` will fail saying `Could not create item free, item is already managed by seed job deployer_root`. In this case, there will be `free` entry in map created by `deployer_root`, and `deployer_folder` will pick it up instead and fail the seeder equality check.

This can seemingly be fixed by using whole `path` in `.get()` instead of `jobName`.

Both of those bugs were found in 1.74, but I am fairly sure the issue is still present in 1.76, since no changes in that java file were made.