PagingData is just a stateless stream of incremental load events, so it does not hold this kind of state.
However PagingDataAdapter / Differ (and similarly other presenter-side variants), already need to hold the data, so they expose APIs such as PagingDataAdapter.snapshot() which can give you the current list of presented items.
Keep in mind that the presented data is post-transformation, may not include pages that were dropped due to exceeding maxSize, and also may race with fetcher as it takes some time between loading the data, and having it show up in UI.
It really depends on what you’re interested in tracking exactly, but from the fetcher side (tracking pre-transform) you can either build the list from results returned in PagingSource or you can also write a no-op .map() operator on PagingData which will see every item (but not give you information about order).
Unfortunately Paging3 doesn’t yet offer a non-ui collector that can build this state for you (most useful in testing), but this is hopefully something we can look into in the future.