Code change:
6. <ins> The timeline track provides data about the previously published groups and their relationship to wallclock time, media time and associated timed-metadata.  Timeline tracks allow players to seek to precise points behind the live head in a live broadcast, or for random access in a VOD asset.  A timeline track may also be used to insert events at media times which do not correlate with Object boundaries.  Timeline tracks are optional.  Multiple timeline tracks MAY exist inside a catalog. 6.1. The payload of a timeline track is a UTF-8 encoded CSV text file. This payload is formatted according to RFC4180 "Common Format and MIME Type for Comma-Separated Values (CSV)" Files RFC4180.  The separator is a comma and each line is separated by a carriage return. The mime-type of a timeline track MUST be specified as "text/csv" in the catalog. Each timeline track begins with a header row of MEDIA_PTS,GROUP_ID,OBJECT_ID,WALLCLOCK,METADATA.  This row defines the 5 columns of data within each record. MEDIA_PTS: a media timestamp rounded to the nearest millisecond. This entry MUST not be empty.  If the Object ID entry is present, then this value MUST match the media presentation timestamp of the first media sample in the referenced Object. GROUP_ID: the MOQT Group ID.  This entry MAY be empty. OBJECT_ID: the MOQT Object ID.  This entry MAY be empty. WALLCLOCK: the wallclock time at which the media was encoded, expressed as the number of milliseconds that have elapsed since January 1, 1970 (midnight UTC/GMT).  For VOD assets, or if the wallclock time is not known, the value SHOULD be 0. METADATA: a flexible field holding arbitrary string metadata. This field may be empty.  If not empty, it MUST be enclosed in double quotes.  A double-quote appearing inside this field MUST be escaped by preceding it with another double quote. 6.2. A timeline track MUST carry a 'type' identifier in the Catalog with a value of "timeline".  A timeline track MUST carry a 'dependencies' attribute which contains an array of all track names to which the timeline track applies. 6.3. The publisher MUST publish a complete timeline in the first MOQT Object of each MOQT Group.  The publisher MAY publish incremental updates in the second and subsequent Objects within each GROUP. Incremental updates only contain timeline events since the last timeline Object.  Group duration SHOULD not exceed 30 seconds. 7. </ins> A WARP publisher MUST publish a catalog track object before publishing any media track objects.

Related discussion:
text: This PR adds a definition for a timeline track format, along with details about how to identify timeline tracks in the catalog and how to update timeline tracks. and
I like it! Regarding "The publisher MUST publish a complete timeline in the first MOQT Object of each MOQT Group." it means that the first object of the group strictly inflates with time. For an open range track (for example a 24/7 video channel), it may become excessively long. We may allow summarization of old times in the timeline csv.
A special ‘timeline’ track is produced which describes the availability of groups and objects with respect to media time and wallclock time. May also carry media time events which can be used by the player in constructing a UI, for example “Goal”, “Penalty”. This track can be used by the player for seeking to request specific portions of a DVR window in a live stream, or to any portion of a VOD asset. This may be used for advertising insertion at a later date. In the proposed structure below, the metadata field may be empty. If present, it must be enclosed inside double quotes and may hold any string data. In this example, JSON and XML metadata entires are shown.
I like the idea. Note that some have advocated for KLV as the support for timed metadata for live video. Here is a Demuxed talk about it a couple of years ago URL