Split structure_sync.data.yml to reduce risk of conflicts

Agreed. If core doesn't do it this way, why should this module? It also makes revision control with Git clearer. You'd be able to see what types of things changed just by looking at what files changed (without having to look inside).

New features are supposed to go into HEAD, but there's no dev branch available. I created #3070348: Development branch release node is missing for that.

New features go into HEAD, which may turn out to be a 2.x branch if we have one.

I just want to add my +1 to this, git doesn't diff the current file well at all. It is all over the place. Sometimes it has even changed the order of keys (taxonomy and menu flipped recently between our environments!)

What might be helpful is a method similar to config sync where it will tell you what changes will be made on export import (remove, update, add)

Theoretically if you were merging from branch1 to branch2, you could check out branch 2 and import its config, safe-import everything, then export everything export config. I haven't nailed that down yet, and it's a lot of manual steps, but it's an idea.

This would help too: #3213758: Stop setting term IDs when exporting taxonomy terms.

This would be great, a step towards https://www.drupal.org/project/structure_sync/issues/3085904 getting more generic.

I propose to avoid introducing BC breaks and be able to import from structure_sync.data.yml if the others are not present.
Adding a warning on the export saying "Please remove legacy structure_sync.data.yml" or deleting it programatically could do the trick

How to handle this issue without creating BC breaks/new major version?

Maybe something like:
On any export, export to the new splitted configuration(s) and delete the corresponding part from legacy config
On import, for each entity type, if we find data on splitted config, use this one, if not, try the legacy config file

We need to make sure to handle entity types separatly.
Users may use structure_sync for all entity type but export only one time for some reason and wouldn't expect entities disapearing

We should then deprecate the usage of the old structure_sync.data config and plane to delete it in a next major version

~~~

Other possibility would be to work on a new major version where we simply ask to users to re-export everything after major version update

+1 for this feature. We have encountered the issue several times now. It even doesn't necessarily involve several developers but a single developer might have hard time figuring out what the conflict with the structure data YAML file is.

We have used Fixed block content module in another project and it splits for example each block config into a separate file and we haven't had the same issue there.

I think it would make sense here also because each block, taxonomy and menu is a separate configuration in core also so you would have a linked structure file for it.

Maybe this could be handled in a new major version. It could be a manual process when updating or perhaps an automated update hook.

Going to add my +1 here as a very desired feature. It is extremely difficult for developers to git diff the current structure_sync.data.yml file when ordering of the keys change, tid changes, weights and multiple entity types (taxonomy, block, menu) combined.

Just another +1 here for all the same reasons everyone has already stated.