That oddness is due to the way the endpoint is working internally – we’re actually merging two different lists of data, one of which is internally paged at constant size. Each request is looking at all channel installs for the requested extension, and then filtering by the listing of live channels. The strategy could potentially mean 0 returns and a pointer to another page, which I realize is irritating.
This particular endpoint has been a pain point since launch for us; we have chosen to use the current page-then-filter method because it allows a predictable load and return time on the underlying data for each call. There is much room for improvement; our first priority has been making the system stable for both ourselves and developers. I think we’re almost at that goal with some additional changes planned to go out soon.
I can’t speak to our roadmap, and I don’t know where refactoring the service for a better data strategy would fit on a calendar, but making this call significantly more efficient and paging the public response only when necessary are both things I would like to do.