Thanks for the reply, SeanKohler

I was able to recreate the simple sort like you did, and the behavior was the same as what you shared (property values were displayed in the order that vRO returned them to vRA).  However, it seems that the behavior is different when dealing with properties that are linked to vRA constructs such as Reservation Policies and Network Profiles.  If you don't mind tumbling a bit further down the rabbit hole with me....

vRO 7.x comes with an OOTB script action called "getApplicableReservationPolicies" (located in the [com.vmware.vra.reservations] module).  I have copied the OOTB action into one that I can tweak on my own.  The first 17 lines of the script remain unchanged.  I also did not touch the function defined at the end of the script.  Here's what I changed.

VMware's code (lines 18-22) :

var reservationPolicyProperties = new Properties();
for each(var reservationPolicy in reservationPolicies) {
  reservationPolicyProperties.put(reservationPolicy.getId(),reservationPolicy.getName());
}
return reservationPolicyProperties;

My code (replaces the above, inserted above the function defintion):

var reservationPolicyProperties = new Properties();
var resPolNames = new Array();
//capture an array of the Reservation Policy names
for each(var reservationPolicy in reservationPolicies) {
  resPolNames.push(reservationPolicy.getName());
}

resPolNames.sort();
//sort the array of Reservation Policy names
//step thru the sorted Reservation Policy names; insert them into Properties object in alphabetical order (by name, assuming the sort worked)
for each (name in resPolNames) {
  for each(var reservationPolicy in reservationPolicies) {
  var retrievedName = reservationPolicy.getName();
  if (name == retrievedName) {
  reservationPolicyProperties.put(reservationPolicy.getId(),reservationPolicy.getName());
  }
  }
}

//write the results to log; note that keys is never sorted, so presumably, we are stepping through reservationPolicyProperties in the order they are returned to vRA.
var keys = new Array();
keys = reservationPolicyProperties.keys;
for each (var key in keys) {
  System.log("Key: " + key + "| Value: " + reservationPolicyProperties.get(key));
}

return reservationPolicyProperties;

The output in vRO scripting.log (generated by the loop in lines 21-25 of my snippet) shows that the sorting/property insertions I performed above (lines 03-16) seems to have worked the way I wanted (the properties object appears to be sorted by Names of the Reservation Policies, highlighted with red text):

2017-02-22 17:38:28.827-0600 INFO  {cafe-IDGbGg2xvA@vsphere.local:} [SCRIPTING_LOG] Key: e611971f-c42c-4307-98b0-4785833eb3c0| Value: BN-CRP-HYBRID-01C - EUC Team

2017-02-22 17:38:28.828-0600 INFO  {cafe-IDGbGg2xvA@vsphere.local:} [SCRIPTING_LOG] Key: 1c558a75-1ad7-40a6-ba49-97d20d857247| Value: LB-CRP-GEN-01C - Cloud Team

2017-02-22 17:38:28.829-0600 INFO  {cafe-IDGbGg2xvA@vsphere.local:} [SCRIPTING_LOG] Key: 275ec551-7bd6-4841-9361-b648543d73da| Value: LB-CRP-GEN-01C - Enterprise Operations

2017-02-22 17:38:28.830-0600 INFO  {cafe-IDGbGg2xvA@vsphere.local:} [SCRIPTING_LOG] Key: 8a342a96-cb1b-4ab9-a6c3-133c1711e651| Value: LB-CRP-GEN-01C - SQL DBA Team

2017-02-22 17:38:28.831-0600 INFO  {cafe-IDGbGg2xvA@vsphere.local:} [SCRIPTING_LOG] Key: 9005d4d2-635b-4e56-a663-c05d3d3fde8f| Value: Nutanix_Lab - Cloud Team

2017-02-22 17:38:28.832-0600 INFO  {cafe-IDGbGg2xvA@vsphere.local:} [SCRIPTING_LOG] Key: 8395c8a7-6a82-413b-b61d-aceb728c0cce| Value: Nutanix_Lab - Enterprise Operations

2017-02-22 17:38:28.833-0600 INFO  {cafe-IDGbGg2xvA@vsphere.local:} [SCRIPTING_LOG] Key: 20d089b9-5ccc-41dc-beef-1d2c5b1dd877| Value: RASC_Lab

What vRA displays however, is in a different order:

My Script Results	VMware Script Results (in vRA Catalog)

It's interesting that there is a slight variation on the display order (in the vRA Catalog Request) between my script and VMware's script.  I had been guessing that vRA was sorting the list based on some other property behind the scenes, but the fact that there are differences here lead me to believe otherwise now.  To that end, I looked at the dbo.HostReservationPolicy table in the IaaS SQL server, and based on the properties in that table (and in the associated dbo.HostReservation table), I'm not seeing any solid correlation between properties and how they are sorted/displayed in the property dropdown on a catalog request.  They aren't sorted by name, id, lastmodified (from the HostReservationPolicy table), nor by any other property that I can see in the affiliated HostReservation table.

Here's the HostReservationPolicy table:

If you're still with me and thinking "Dude, this isn't that bad, just deal with it," please recognize that this is a simple example from my Dev environment that I'm using for demonstration purposes. In my prod environment, my end users will have to select the right Reservation Policy out of roughly 100.  Without sorting, I guarantee there will be more user errors, and I really prefer to head those off wherever possible (don't you?!).  I have a similar problem with my Network Selection property (which is also driven by an action that VMware provides OOTB and I copied/tweaked to my requirements), but worst case there is they have to pick the right network out of about 40 choices.  One saving grace in both cases is that they can start typing the name in, and it will auto-filter down based on what they type.  Still, sorting isn't new, and I'm hoping that one of you fine folks can help me figure this out so I can help my end users ward off issues.  Besides, I'd really like a deeper understanding of what's in play here.

If I can't get help here, I may submit this as a feature enhancement request to the vRA product team.

Thanks in advance for any help you cats can offer here!

GrantOrchardVMware, stvkpln, and jadelzein -- you seem to know a thing or two about this; tagging you in hopes you can offer insight?

Sorry I kinda went dark yesterday.  Appreciate the responses. 

In Reply #4 you observed using property in a unique way.  I agree, and this threw me for a bit of a loop, but I didn't want to alter the structure of the data returned to vRA from what VMware provided OOTB.  Thus, I'm 100% piggybacking on what VMware provided in their OOTB script action.  I used the same call that VMware made to create the data being returned to vRA ( reservationPolicyProperties.put(reservationPolicy.getId(),reservationPolicy.getName()); ); I just wrapped my own logic around their statement in an attempt to sort it presentably for my end users. 

To answer your query in Reply #6:

This is a custom property dropdown in an IaaS Blueprint.  Its name is the reserved/special property "ReservationPolicyID"  (more info here:  vRealize Automation 7.2 Information Center)

Here is the property definition.  I blacked out the name of our module where the script action resides to preserve anonymity and avoid IP/Legal concerns, but any one of you (with vRA/vRO 7.x and an ounce of ambition) should be able to wire this up with VMware's OOTB action (located in the com.vmware.vra.reservations module) and observe the same behavior. 

To catch up to exactly where I'm at, you would copy that action into one of your own, and replace the code like I described in Reply #2 on this thread.  Then update your property definition to point to your newly created action, apply the property to a blueprint, and fire up a catalog request against said blueprint.