Moving headers around is actually the most important part of the changes I did for the separation prototype, but it is no easy feat at all.
Now that every important header is in the same folder, there are no restrictions over what uses which. The idea I followed for the separation was to move headers as close as possible to the sources. Taking for instance AboutDialog.h, the first one, it should be next to AboutDialog.cpp, nothing in src/core has any reason for using it, so why make it avaliable there?
Probably the intention here is just to move the whole folder just to inside src, but the closer, the better 😅
I am happy to help on this matters, as they will reduce the diff with my branch, but would feel safer to wait until there is a 1.3 branch to make sure no obscure target or configuration gets inadvertently broken.

it is no easy feat at all.

That's why i opened this discussion before starting any work in order to not waste any work.

I appreciate your comment. I won't be starting any work for some time (atleast till i get nods from the main devs)

I don't really have issues with committing time and effort. It's just a matter of "will the change be welcomed?". Also, I will do everything in a single PR as breaking the changes into parts will only complicate things for me.

I like the idea. It's good to separate public headers from private headers. And besides the benefit for core separation, it would also let people know which headers can be used in LMMS plugins for example.

It might be worth mentioning that we already have at least one source file which has a private header.. See src/core/UpgradeExtendedNoteRange.cpp whose header is located in the same directory.

I think I'd be fine with following that convention for private headers - basically just move them from include/ to wherever in src/ their corresponding cpp file is. Unless people have different ideas for how to structure things.

Doing this will likely create merge conflicts in many open pull request. This should be taken into account as well. There are already several pull requests with merge conflicts due to other reorganizations and I guess increasing the number of these PRs will also decrease the chance that the respective developers will fix them because it will just become too much effort.

Perhaps the PRs should be managed/pruned before doing this?

I wouldn't do any more rearrangement stuff this large until at least after 1.3 has been released.

Okk i will wait a bit more then, atleast till some old PRs get merged.