[bluGill]

That won't help. I've worked with graphical programming languages before. They work well enough, but in every case I've seen the files saved are not merge-able. Even code generation tools a trivial change will sometimes result in saved files that are almost entirely. Even with text based coding, sometimes you have to make major changes to a file and you tell everyone else on the project don't touch that file since their changes will not merge - the difference is because you are working with the text you know this will happen.

What you want is something that allows more than one person to work on a project. Programming started with file locks - you can divide a large project into pieces (parts, sub assemblies...) and then lock those pieces. I think that is done by the better CADs already, if not it is easy and you should apply that.

Eventually we figured out how to create merge tools - break the program up into lines, and if a line is changed by only one person apply the change, otherwise make sometime redo that line manually. Until you figure out how to merge graphical drawings you are stuck. Making the file next based isn't going to fix anything because the tools will sometimes need to restructure the file based on what seems like a trivial change.

[rjsw]

There is current work in STEP AP242 to annotate parts of a design with UUIDs to make it easier to work out if elements of a saved file are new or modifications of a pre-existing one.

[bluGill]

UUIDs don't tell you that because when does changing a part make it a new part and thus a new UUID? Unless the users is naming all parts - but that isn't what UUIDs normally are and opens a different set of problems.

The problem is hard. I wish those working on it luck, but I don't have high confidence that it is solvable.

[rjsw]

There will be an algorithm defined for CAD systems to follow on when to keep or replace a UUID.

[marcosdumay]

IMO, graphical languages should have graphical merge tools. You can't expect the text to be mergeable, but it's not enough reason to refuse file diffing as a concept.

The problem is that graphical tools are usually large, proprietary software made with the explicit purpose of locking people into an entire ecosystem. Diffing is a small specialized operation that enables portability and interoperability between ecosystems, so tool creators actively avoid those.