No. Paginate is restricted to one single item per page.
Once it ran it’s done and any subsequent call will use the same result. This is due to it’s resource-hunger. I have a site with around 2k posts and was paginating through them (number pagination, 10 items per page). that took 3 to 6 minutes until i removed it and just started using next/prev navigation.
Create your own pagination with a partial that runs through a selection of pages. Select the pages with where and in and all these nifty section commands. Hand a dict containing pages to that partial, then do some magic (total number of items, items per page, current page as parameters) and find a way to cache that properly, because it will be a very time intense procedure.
An idea: Maybe the newly introduced page.Store (very undocumented) might be helpful. It works like a page scratch that is saved over the whole hugo run, if I get that right. I have the feeling that might be in some magical way useful for this.
There will always be the issue, that you don’t know which page Hugo will run first - so using paginate will still not work here, but the times to create the pages-object you want to create a pagination for and the main variables you want to create might be done once and cached and independent of the amount of pages you want that created for. Maybe. Didn not use page.Store yet.
But in the end: There is the point of usability: what is the reason for this pagination? How would people use it (hint: they don’t, my number pagination was never used, only the next/prev arrows on it).