Creating multiple versions results in random ordering for "default version" processing

Given:

POST /GROUPs/gID/RESOURCEs/rID/versions?meta&setdefaultversionid=v2 
{
  "v1": { },
  "v2": { }
}

(setdefaultversionid is not allowed to be missing or "null" so we know which is "default")

Result: New resource is created with 2 versions, v2 is the "default"

Then do:

POST /GROUPs/gID/RESOURCEs/rID?meta&setdefaultversionid=null

(request to remove sticky flag)

Result: Sticky flag removed, but it is random as to which version becomes "default" since it's based on creation timestamp and the order the original Versions were created is random

Question: why is it ok for this to be random, but not for the original POST to have a random result?

Options:

Leave it as it
Remove REQUIRED setdefaultversionid on original request (make it a STRONGLY RECOMMENDED), and get random result - but at least we're consistently random
Require servers to create the Versions in alphabetical order, thus it's not random. May not be what the client wants, but it's not random
If there is a "createat" timestamp, use it for ordering but do not persist the value - at least we preserve the order for the import case
If there is a "createat" timestamp, use it for ordering and persist the value - no longer a readonly attribute under server's control

In general, should someone be able to specify the ordering when bulk-creating versions without being forced to create them one at a time?

Proposal:

option 3, and any versions w/o a "createdat" value are added in random order first (so they're oldest). This will at least give the client the option of ordering them if they want. Exact TS values are irrelevant, just their relative values are what matters

Note that in the case of there being existing Versions, all new Versions will be "newer"

xregistry / spec

Creating multiple versions results in random ordering for "default version" processing #88