Retrieving ImmutData from the network to validate the app's binaries/resources itself can occur even without version dirs or versioned files even. Just need ImmutData for it or if SD, the hash check would have to be kept elsewhere to confirm the retrieved content hasnt changed. Versioning can be seen as a convenience at that point almost and shouldn't be a requirement.
This certainly is an interesting thread and I think there are quite a few points to take and consider in detail from this as a combination rather than 1 answer fixes all.
Some general points mentioned such as "Launcher highlighting-to/educating the user the importance of allowing an app access" vs "not overloading the user with too much where the user results to just spam approve stuff" is a tricky but essential balance.
In the current scenario launcher pretty much does barely any fingerprinting and leaves it all upto the user to decide which is what raises the bunch of questions of what if the user was misled by any means. This certainly needs looked at too.
App based sandboxing I see as an important feature, just personal pov. Without it dont see a decent way for one app to store info which is private to itself and the user. Ofc user has the ultimate authority to remove this app and its data too, so not talking abt not being able to do that. Just one app impersonating another.
Even with the low level API app's use their own specific encryption keys, so content stored via one app cannot be "understood" by another app. However since all apps use the same signing key of the user, the second app can just mutate the data and thereby cause the problem. To fix this(an example) the network could allow an account to have sub-signing keys or sorts which the vaults will allow to mutate data with but the users main signing key can ultimately override ofc. This way even via the low level API, apps cannot understand nor mutate data stored by a different app. This is an approach that has been raised and discussed. Just hasnt been finalised and made its way to impl yet.
Secondly one app impersonating another. Previously this was a limited scope when each app had a dedicated channel via which alone the launcher would communicate by and that way the launcher also knew when that app say went offline. With the client-server model detecting presence gets a bit more tricky unless it was again websockets or something which was used / heavy pings to detect presence with challenges(cumbersome).
Launcher could fingerprint in a more verbose manner say via token validations. so App asks launcher for approval, user chooses to provide access. Now launcher provides user a token say "ABCD" and asks user to input that back to the app and when the launcher receives that from the app, it trusts its validity. This ofc plays a lot better with a dedicated channel for launcher to detect when the app has terminated and remove this token / cleanup accordingly. Negatives for such an approach ties to that general point balance of now user needing to shuffle between these two things to approve an app and so on and how well/secure is it when there isnt a dedicated channel(maybe its ok without one but needs confirmed).
Now while these points (extended fingerprinting, dedicated comms channels, low level api and also general apps using their own sign keys as sub keys of user sign keys, launcher educating user abt importance of app authorisations, ...) are all valid points and I'd certainly vote for some/all of them and maybe more too after considerations, in this specific case, I'd think none of this would have helped what occured here.
Even with all these measures, the app here
SafeEditor(neat app btw, lol soz I'm using this to explain what I mean) made it clear to the user it intends to impersonate another app AND the user was "ok with that". In SAFE the user always becomes the ultimate authority and if the user chooses to be ok with one app impersonating another, not much I see standing in the way after that.
Now ofc, user was ok with this app impersonating another cos it promised to give functionality the user did not otherwise have and the user chose to trust it cos well @DavidMtl aint a bad guy and its just impersonating demo app with not that secure info or something. Is that always going to be the case though?
So say if I built an app and asked users to allow my app to impersonate their safecoin wallet app with the promise of providing better performance, users might not be so willing, if i did promise free safecoin, some prolly do take the gamble and if they loose what they have, would rage quite hard. Again I'm not saying this to indicate we dont need any fingerprinting, I think we need quite a few bits as mentioned above but there prolly is another dynamic here too in terms of should the user be the ultimate authority. Personally I feel the user should be cos if not just as mentioned in this thread, I can build an app that pretty much takes the users credential from him and in this case since the user gives that to me willingly, I've got access to everything and game over.