I think what may be happening here is that vCD's placement engine finds a "better" solution by putting the disk on the other datastore: it suffices that the other datastore have more free space for this to be true. We currently (I believe but will verify) do not have a soft affinity constraint to tie the disk to its original datastore when feasible (i.e. when that datastore has enough free space to accommodate the disk delta requirement).
VCD's placement engine does *try* to keep items in their current datastore. However, there are many caveats which result in the item being moved. There are also a few known bugs in this area, which have been resolved.
If you could provide logs, as well as information about the request that expands a VM's disk, that'd help us figure out why the disk was moved in your specific case. Depending on whether this is a case we've already encountered, or a new scenario we haven't covered, we can either suggest an upgrade to a build that should resolve your issue, or try to address it in a future release.