Currently, the paging limit for categories is controlled by the $wgCategoryPagingLimit configuration parameter. This paging limit controls both the number of pages and files displayed in a category. Although listing 100 or 200 pages is acceptable, doing so for images may not be desirable.
Thus, it would be beneficial to have a configuration parameter for the maximum number of files listed in a category, e.g., $wgCategoryImageListingLimit or a similar setting.
In fact, there are 3 things displayed in a category:
Instead of a new variable, I suggest changing $wgCategoryPagingLimit to be an array, to allow a more fine-grained control:
$wgCategoryPagingLimit = [ 'pages' => 200, 'images' => 200, 'subcategories' => 200, ];
If defined as an integer in LocalSettings.php, it would mean using the same value for all 3 items.
Looks like I am not the only one linking this. Thanks for your feedback. Yeah, your suggestion for improvement is even better. I forgot about subpage listings.
These variables would only allow changing the limit sitewide, and would also need backend access since they need to be changed in LocalSettings.php.
It would instead be better to allow more pages/images/subcategories to be displayed on a case-by-case basis by adding limit= to the url, similar to how it works on Special:Contributions or page history etc.
Thus, 200 can be the default, but an end-user can choose to view (e.g.) 500 items just this once by manually changing the url (or clicking some presets like on the above examples).
What problem does solve your proposal that makes it better?
What's asked here is to control the default paging limit when you view a category page. For example, a large list of pages in a category doesn't seem like a costly operation, but when we talk about thumbnails of images it can have a performance impact, specially if the thumbnails need to be generated on demand.