Can confirm the issue is still present on trunk, and it also seems to work with Special:recentchanges:

{{Special:Recentchanges/5}}

{{Special:Recentchanges/1}}

will display 5 entries both time.

However, the issue does not seem to be present with {{special:prefixindex}}

Caused because both Special:Recentchange and Special:Recentchangeslinked both store configuration in a member property of the special page objects.

In SpecialPageFactory::getPage there is a line:
self::getList()->$realName = new $className;
Which causes the special page objects to be re-used if a special page is called multiple times in one request. Thus the same config is kept for both transclusions.

Possible fixes is to not re-use special page objects when they are being transclude, or to make sure the special pages clears the options property in the execute method each time its run.

(note as an aside, this is a regression in 1.16 and is not present in 1.15)

It looks pretty wrong to return the same object for multiple calls here; this might be some old remnant of when the special page objects were just entries for the lookup list and the actual code was handled by a separate function. (A few of them might still do that, but many/most? have been moved to the newer extended class style where the object actually does the work.)

Changed the behaviour in r87781. This shouldn't affect the old style special pages (Although i don't think we have any left)