hi
basically what they are seeing is normal....doesn't mean it cannot be changed though, so interested in your feedback.
when you configure IP customization you should notice extra recovery steps are added to your VMs. one of those steps is called "Guest Startup" and during that step we push the ip customizations to the VM(s) via the VIX API and then we shutdown the VM and reboot it to ensure the changes take affect and are picked up by all of the GuestOS services on restart. you then have what you could class as the actual Power On step that really matters (immediately before the "wait for vmtools" step for each vm) and this power on step will still be carried out in accordance with the priority groups AND any dependencies that are set.
i can see how this is confusing behaviour though as the VM has already booted once during the Guest Startup step but in reality it was only booted to allow the customization to be injected.
so if you think of it in those terms then IF your VM's actually do need their IP's changing to be "useable" at your DR site if we need a poweron/poweroff cycle per vm to inject and apply those changes correctly then actually it IS ok to have those "Guest Startup" tasks execute in parallel and by doing so we help reduce the RTO overall using that parallelism. Also don't forget in this process we are then going to immediately shutdown the VM's anyway, so by running this set of operations in parallel we reduce the time taken to re-IP all of your GuestOS's.
Once the GuestOS's have all got their respective address changes applied we then move on to the "real" Power On tasks as we said earilier and these are the ones that actually matter i.e the final ones where the powered off VM's all now contain the correct tcpip stack and now when the VM's power on they will have their new address that will work in the new address space and the applications will be able to talk to each other. Therefore in terms of adhering to dependencies and priority groups, when customizing IP's it really is only the final Power On that matters or should matter.
hope that makes sense?
....now.....this is where i'm keen to hear your thoughts, the other side of the coin is by doing things this way yes we reduce the overall time to re-IP but this means that if you have VM's in specific priority groups like group1 presumably because they are the most critical the RTO of that group IS affected by the fact we execute all of the "Guest Startup" tasks across the whole plan in parallel. So one option might be to include a configurable setting per recovery plan that allows you to choose to adhere to strict priority group / dependency setting sequencing even for the customize ip "Guest Startup and Guest Shutdown" steps. This would impact the RTO now of the overall plan but would allow the higher priority groups to not be affected by their lower priority siblings.
does that sound useful? any other ideas or thoughts great to hear. cannot promise we can get it added in by next week 
but i can certainly get it raised and reviewed as a feature request.
cheers
lee