Comment 137 for bug 1575053

Hmm. it's a solution that fixes that different than everywhere else by-design behaviour -->

--> As I understand the idea is to have a system that hopefully won't grow/clutter itself by installing/uninstalling applications as system is used in time (like Windows still does and Linux to some extent (albeit it's very easy maintainable in Linux) too - so it will not require reinstallation from scratch from time to time to achieve acceptable performance? Also possible security benefits of not leaving unmanaged data behind. Brave, but I'm not sure it's really worth it.

I am likely to accept and adapt to such a workflow but then these questions arise:
1. Assuming that snap itself comes usualy as a deb package it won't delete the data (including snapshots) it created itself during it's use, would it? (No other sane deb-installed service would AFAIK as I pointed earlier.)

2. Similarly to ie. Android when application is removed all the data from application's dir under snap home dir is also deleted (soon(?) to leave an always done on-remove-snapshot). I think I would still like to be always asked by snap commands (text UI, graphical UI) if I really want to remove some app. Game saves, edited photos, music, databases of apps that are strictly confined and not using home dir access (for whatever reason) to place their run-time created files come to mind (these would most likely be also lost in Android unless backed up using some Google's backup APIs or saved to shared space/"sdcard").

To not to be off-topic - /home/snap is still ugly as hell, wasn't it an option to become /home/.snap in the begining of a project?