Custom Properties can only have one definition. We've run into this limitation as well. Can be super frustrating. I'm hoping someone else chimes in with a silver bullet on how to get around it like you'd like to, but I wouldn't hold my breath for that.
We have addressed this problem specifically by tweaking a vRO Action that VMware provides out of the box (OOTB). If you're unfamiliar with vRO Actions, they are basically script tasks that can be plugged-in to workflows, or, now with vRA 7, can be linked to vRA custom properties. To view the Actions in your vRO, open your vRO client, and select "Design" on the "Run / Design / Administer" dropdown. The workflows tab (you should be familiar with this?) is on the far left; The Actions tab is second from the left.
The OOTB action you'd be interested in here is under com.vmware.vra.networks, and it's named "getApplicableNetworks".
When you link it to a property in vRA, it will produce a dropdown that contains a listing of ALL networks that are available in ALL reservations that the user has available to them. It's not a perfect solution to your challenge, but it is a viable workaround with some caveats. I guarantee that your users will select a network that is not applicable to the cluster they are attempting to build on.
In my environment, I have created my own duplicate of this OOTB action, and modified it to accept an input of the ReservationPolicyID property (vRealize Automation 7.2 Information Center), and return a filtered list of networks that apply only the ReservationPolicy (which is effectively the vSphere cluster) that the user has selected in the catalog. This allows the end user to select the cluster they will build on, and then pick a network from a list of networks that are enabled on the reservation for that cluster.
It works a treat, but the networks aren't sorted in the vRA catalog. I'm trying to get help from the community on that with this thread: Sorting properties returned via custom action
Hope that helps...
