Dependencies editor

I have probably miss something in the way to use the dependencies editor.
I need to create several sets of jobs, with dependencies between jobs within a set.
Should all the sets be edited in a single view or is it possible to create separate views
in the editor, one view for each set, as an example, one view per "Folder"?

There is only one view, consider this view as a workspace. All job sets should be linked there.

In case if you need simple dependencies like a job chain, you can use "on finish" notification action with "run another job" action directly in the job properties to chain jobs together.

The way it is implemented (only one sandbox) creates messy and dangerous situations.
After having created dependencies for a second set of jobs (about 12 jobs per set), it happened
(the reason is not clear) that cross dependencies has been created between certain jobs
of the two sets. By know I have not yet recovered the mess it has generated.
It should be reasonable and more secure to manage graphically the sets in separate contexts.

The Dependencies Editor is simply a graphical interface for viewing and building dependencies (e.g. job properties), in other words, it can be used for graphically updating certain job properties. These dependencies are not stored in the editor or some separate place. In fact, if you change job properties using some other method (Properties Wizard, script jobs, API) and then open the Dependencies Editor you would see these changes reflected on the dependencies diagram. That's what likely has happened in your situation. You changed some job properties directly and when you reopened the editor you found a different picture there.

The Dependencies Editor shows the entire state of your active job database file where all the jobs are stored, that's why there is a single workspace for display of the job database internal relationship model. Please note that only semaphore-based dependencies are displayed in the Editor, all other hard-coded types of dependencies are not (such as dependencies based on job starting from a job script or external batch file, or job linking using run-another-job method)