No it is not poor design.
From the legal point, behind a vendor exists a juristic person. This person has contact information.
I wrote it for juristic person linda, not natural person. A company IS a juristic person, if you do not believe this ask your CEO.#
The design is for a normal shopowner very easy. He installs vm and the one who installs vm is the vendor with id=1.
What you do is a bit more complex. You install vm for your customer, because you are an agency. Then handle like a professional one and not amateurish. You have three possibilities.
1. Give your customer your admin account and everything is clear.
2. Create another Superadmin account for yourself.
Done
OR
1. Create a superadmin account for your customer and
2. use the tools to set him as mainvendor
http://dev.virtuemart.net/projects/virtuemart/wiki/ToolsDone
OR
1. Create identity (user) for the company
2. Use the tools to set this mainvendor
2. Create an admin account for your shopowner
Done
In single vendor mode, everyone allowed to enter the BE, acts automatically as the mainvendor. So every superadmin can change the email of the mainvendor.
So I do really not understand your problem.
I think the real problem is that you do not understand that from juristic view point a vendor IS ALWAYS a person. Why we should create a new entity for this? Even the Shipment Addresses makes sense for vendors, they are then just the addresses of their storage.
So how it should be done else? Every other solution has a lot more inconsistencies. In vm1 you had to change the email address 3 times! One time in joomla, then for the user and for the shop. Yeh you like this more? Maybe you 5 people would be calm, but ten other would be angry, saying "hey why I have to change the email address 3 times, if I give the shop to my customer". We had another table for vendors before and I noticed a vendor has exactly the same data as a normal user. Checking the juristic point I found out that a vendor is exactly the same as a shopper, just with some extra information.
We bind all identities to the joomla login, because this is the informatic way to determine a identity (we call this procedure login, btw). So we just extend this identities. Be aware vm2 is multivendor (we use it that way). So your system must be also able to handle this.
It is just a matter of the view point and knowledge. If you know that the vendor is handled as user and if you know that you could handle it as own identity, what is left?
The system makes it possible that
1. shopowner login == identity of the store
2. shopowner login != identity of the store
3. Many admins can handle one store and act as this store
4. Mainvendor can act as store and vendors can act as employed subvendors
5. Mainvendor can act as store and vendors can act as vendors
Just for point 5 we need some extra stuff, like the multicart system. But this is another topic. Topic 1-4 work, you assume that the system must just feature topic 2. You do not know how to achieve it and say it is poorly designed.