Time ordering of Coverages in a Collection

In the particle tracking use case and drift models, the usual outcome is set of:

• trajectories - from drift models they are identifiable along the time, something like NCEI Multiple mooring lines with stationary instruments at different depths across the mooring lines and the instruments measuring at different points in time. but without 'z' in dim.
• series of snapshots, each snapshot is a MultiPoint, each point has properties - good for raw observations, particles are not identifiable at source, also preference for visualization as it allows for present frame by frame.

Here is the covjson schema compliant second representation as CoverageCollection of MultiPoint, each Multipoint at different time:
https://github.com/ILIAD-ocean-twin/data_access_api/issues/12

Traversing through all the Coverages/frames to know what are the timestamps and to order them does not feel like elegant.
So example has additional time domain (not breaking the schema nor mentioned in spec as MAY for CoverageCollection) on the collection level where all the timestamps are listed and sorted. It is redundant to timestamps in the Coverages while allowing to construct timescale, potentiallyy faster (all timestamps in one block, no need to traverse all the Coverages, esp they does not have to be in order).

Is that a good case to say what is the domain of the coverage collection if exists?
Is it a good candidate for #161 type profile?

Start by reading the linked data_access_api issue #12, the proposal for a collection-level time domain, and the referenced CoverageJSON specification section. Determine whether sorted collection timestamps and coverage ordering belong in the schema or a #161 profile, then document the agreed behavior and completion criteria.