[MU4 Issue] Multi-instances: different versions of MuseScore should not communicate

[cbjeukendrup]

Describe the bug
In principle, stable and pre-release versions of MuseScore should be able to be installed independently, and never influence each other in any way.

But with the multi-instances system, all versions of MuseScore 4 will communicate with each other, share settings and other stuff, and mess things up, even though they still use distinct folders for app/user data.

To Reproduce
Steps to reproduce the behavior:

1. Have a stable/released and an unstable/development version of MuseScore 4 installed.
2. Have both running at the same time.
3. Change settings in one, and see that these settings are propagated to the other one. That should not happen.

Expected behavior
So, stable/unstable versions should only communicate with other instances of the same kind as themselves.

We might also want to take the version number into account, i.e. version 4.0.1 cannot communicate with 4.0.0. Or even just the path to the executable, to make sure that only instances of the exact same build can communicate. The could prevent "miscommunications" between versions, that might occur when we change how instances communicate exactly. I'm not sure whether we would want to do this though.

Platform information

• OS: reported on macOS

[jeetee]

"We might also want to take the version number into account, i.e. version 4.0.1 cannot communicate with 4.0.0. Or even just the path to the executable, to make sure that only instances of the exact same build can communicate."

I fear this might be overly limiting and might lead to unsynched settings/palettes if one (for some reason) runs different minor versions in succession.
Under normal operation, a user is somewhat expected to only have one of each major release installed anyway. So to me it'd make sense if all builds that use the same settings location communicate. As that, in essence, is the reason to have the communication: to synchronize program wide settings between those instances.

This would indeed make development builds not communicate with release builds; but allows communication of all minor/patch releases with each other within the same major version, rare though I anticipate that situation to be.

EDIT: Then again, afterthought:
Since it is not "normal" to have multiple minor versions available at the same time, let alone run them concurrently; we might not want to prevent users from launching one of those concurrently with another?
After all, if the do communicate, trying to launch an other minor versioned instance would lead to that version getting killed off by the multiinstanceprovider?