Hmm, I would careful around assigning to much application logic into the QVF.
For example, for branch.qlik.com we use MongoDB to store user profiles, user preferences and then we use Qlik to search and filter data from MongoDB.
Now with that said, if you do want to persist those kinds settings into the QVF you can of course. I would probably persist a GenericObject with default settings and then create a GenericObject per user and store that. You can then leverage the standard Qlik apis to interact and fetch those objects and you don't need to introduce any additional server side components.
Luckily our Generic Objects are truly generic, you can store whatever full dynamic properties you want it them. Heck you could even decode a mp4/avi into a array buffer and store that in your generic object if you wanted to (Don't tell our IT)
I learnt the hard way not to get too attached to your QVFs and always store a backup somewhere. Corrupted QVF still occur every now and then, but not as often as in 1.0.
Multiple app export from the QMC would be a real timesaver.
I think I will go with the localStorage approach but attaching additional data to a bookmark might be a possibility in my next/first mashup.
Another option is to use local storage. Easy to implement, but the settings will be stored client side, so if the user uses another device he wont get the same settings (like if you open your mashup on a tablet you will not have the same settings as on the desktop).