To get around this shortcoming, the sharing is mostly one way: from the host to the VM, via the default shared folder. I've not had problems with VBFS when managing files in this manner.
There have also been times where I have implemented watch scripts against files on the host, which triggers a rsync to the guest's normal file systems. From there, the file system behavior is more like what we can expect from a typical virtual machine.
To support workflows similar to what I do against non-local VMs, I've worked up some wrapper scripts which allow me to interact with the Vagrant VM via the usual ssh, scp, and rsync. When running "vagrant up", I also write out the VM's SSH configs and a ssh alias concatenates these with my base .ssh/config file.
Vagrant itself acts as a user-friendly wrapper around the creation and management of local virtual machines.
There are ways to use Vagrant to create and push machine images up to cloud providers, but we're not at a point with our deployments where machines are so easily interchangeable.
http://docs.saltstack.com/en/latest/contents.html http://docs.ansible.com/intro.html
However, I don't do remote development as much anymore since I picked up the habit of using Vagrant locally. Now I can edit the files locally (though still with Vim), and debug them on a local VM. Throw in Salt and Ansible for orchestration, and once I get my local VM working, I know my remote end will work as well.