Based on your question and following comments, I believe we actually point out two different aspect of your problem.
First - why you lose the data. Short answer: because you told VS to do that.
When you debug a solution from Visual Studio, some background check are performed to ensure that the artefact in the solution do not conflict with some artefact already present in the target web site / site collection. If any conflict is found Visual Studio will try to resolve it, based on the specific solution settings (auto resolve, ask, never do anything etc, you can chose it in the solution properties).
What does that mean? Suppose your solution provision a list instance. When you redeploy the solution, VS will perform its checks and find a list with the same name of a list the solution will create. Since that would cause a conflict, it will behave as it is currently configured to do. In your case this result in asking the user what to do.
This also means that since this behaviour is just a Visual Studio feature to support (or most of the time hurt) development, you won't see it when you deploy your code to an actual test/production environment and perform your deployment activities outside VS.
You may then ask how to manage conflicts when manually deploying - and that's is the second point I am going to make. The answer is that sadly there isn't a silver bullet approach: it just depends on the situation you need to handle.
You seem to have problems adding some additional columns to the list. Assuming you are using content type the best bet would be to simply update the CT in the solution - if the list content types are still uncustomized this should be most of the time enough to propagate the update, if that's not the case you can resort to manually push down the changes in a feature receiver. Otherwise, have a look at Feature Upgrading - this post on Chris blog is a good starting point. By using feature upgrades you can write custom upgrade code to manage almost any need you may have.