At the "snapshotter revival meeting" of 21/09/16 (minutes at https://pad.gpii.net/p/2016-09-21-snapshottool-i324n89 ), we decided that for the time being, the only rational policy we can support with respect to solutions which can store multiple user profiles is for the GPII to only read and write to "the active profile".
We determined that every solution must support such a concept - at least at a moment when it is running. If it is not running or has not been run, it seems likely that it can be prodded to do so and hence to decide on an active profile by the "makeConfigurable" rules defined in https://github.com/GPII/universal/pull/462 for GPII-1885.
This policy is reasonable i) since otherwise the snapshotter may find itself reading from one profile and writing to another, which is likely to cause great user confusion, and ii) it is only consistent with our approach to the OS and its builtin solutions. Given the current GPII is positioned as a "userland" application, it will only read and write settings for these builtin solutions corresponding to "the currently logged in user".
Reforming this policy in one area would require reforming it in all, and building some new kind of "user account mapping component" (which is indeed one day envisaged as part of the GPII's user management system) but is a tale for which the world is not yet ready.
Until then, we should reform all of our settings handlers and solutions entries so that they automatically and transparently only read and write to "the solution's active profile" whatever that happens to mean for the solution. The first solution which should be fixed is ORCA which was discussed during the snapshotter meeting. The line
which appears at https://github.com/GPII/universal/blob/master/testData/solutions/linux.json#L369-L386 is faulty and sets up a crazy one-to-one mapping between GPII userTokens and ORCA accounts.
After we have fixed ORCA we should then move on to JAWS, RWG and then any other solutions we have that are afflicted by this problem.