Some of it is insurmountable without having some way of marking a container in the docker-compose.yml as "never destroy this!". It's a UX thing more than a bug, although there was two cases where "docker-compose up" destroyed and rebuilt a volume-only container that was in the docker-compose.yml -- unfortunately it was difficult to replicate so we didn't send a bug report through. The big thing is that using it on OSX with boot2docker means the cache can get confused, and so to get it to pick up config file changes (say, changes to an nginx config that are brought into the container) or some Dockerfile changes requires a "docker-compose rm && docker-compose build --no-cache", which of course will delete the volume-only container unless you're aware enough of the need to name the container you want to rebuild; as I said, it's more a UX issue than a bug, in my opinion.

In terms of fixes, ideally I'd like to see a way of marking a container as "volume-only" -- this would then mean a "docker-compose rm" would not remove it, and "docker-compose up" would never rebuild it.