I am not sure what you mean. The problem as I understand it is that the continuation mechanism cannot take the limits of prop modules into account. E.g. I want to get pageviews for the recent changes; I ask the query api with generator=recentchanges, grclimit=100, prop=pageviews; but the pageview module can only provide data for the first 10 RC items. What should the module in such a situation?

The same thing that a module like prop=links does if there are more links on all the generated pages than it can do in one query. See the behavior of this query for example.

generator=recentchanges is a slightly special case if you're using the default parameters (rcdir=older, no rcstart) since it starts with the most recent changes and on a busy wiki like enwiki there will probably be more "most recent changes" by the time you get to continuation, but the solution for that is to make it possible for a generator to specify an "I started here" value to ApiContinuationManager rather than trying to have every prop module pre-limit the generator. See T146176 for that.

I think I get it now, thanks. So if both the generator and a props module set a continuation, the props continuation will be called until it's exhausted and the generator continuation only after that?

Exactly right. The main motivation for the "new" continuation (remember T96858: Use "new" continuation by default) was to have the server handle that logic instead of making every client reimplement it.

Isn't that still a bit painful from the client's POV? For example mw:API:Query#Continuing_queries has a code example but that wouldn't really be helpful in such a case; instead, the query method would have to keep querying while the same page set is returned, and do some sort of recursive merge on the results. For links that cannot easily be helped since you might need multiple queries to get all the links for a single page. For modules which return exactly one data item per page, returning one fully filled page result per response seems much nicer from the user's point of view. (OTOH maybe most client libraries already deal with this problem?)

Since client libraries have to handle the more complicated link case, the "one result" case is trivially taken care of by the same code.