Only about increasing the max number of multiplexers on the uno/nano (the rest of the comments are under the PR):
that's where the increase probably makes more sense. You seem to imply that a user always wants to define many encoders, but that's probably not the case; if mostly ordinary inputs are desired (think e.g. of a switch panel or overhead), adding some more multiplexers could allow a more efficient use of smaller boards instead of using a Mega just because of the imposed lack of support.

Yes, that's true, it's focussed on encoders. But still shows where the limitation is.

After some more testing I can confirm again, that reading of encoder inputs every 2ms OK, going to 3 or 4ms becomes to be on the edge.
But to make it clear, this does not mean that the max. numbers of multiplexer (or other output devices) can not be increased even without the "FastIO" access, unless encoders are connected. For now these input devices are read in every 10ms, and a longer read in time for e.g. 8 multiplexer (~4,8ms) does not affect the encoders. But if encoders would be connected to multiplexer, we had to read them every 2ms. As the time to read them in is ~4.8ms they get read in every loop(). This results in a not always propper identification of the direction of the encoders.

So having an own device type for "encoders on multiplexer" might be a good way as Sebastian has alreday proposed before.

For a lot of inputs we have also the input shifter. For 128 inputs they need the same number of pins on the Arduino, less memory from the device buffer and they are faster. Up to 96 inputs the even need less number of pins on the Arduino.

As I already mentioned, encoders can already be attached to multiplexers, not using the multiplexer values read during the normal polling loop, but reading their own inputs directly without interference with other multiplexer operations (i.e. regular inputs), and totally with their own independent timing.
Using a dedicated multiplexer for encoders has no technical reason whatsoever for timing, it is just a personal preference because it is arguably more comprehensible for a novice user from a configuration or wiring standpoint.
And while it is true that there are other ways to expand "regular" inputs, it's not necessarily a good thing to limit the user's choice (which often is not arbitrary, e.g. existing installations).
I could also argue that multiplexers can also be slightly faster than shift register chains, besides being much more flexible in not creating processing latency. However, this would require some (quite feasible) changes in how the polling loop is currently managed, so I'm not interested in making a point of it; maybe a matter for a future modification.

In preparation for implemeting encoders on multiplexer the access to I/O's should be increased.

This should not really be necessary.

But if encoders would be connected to multiplexer, we had to read them every 2ms. As the time to read them in is ~4.8ms they get read in every loop().

If I understand correctly what you mean, this issue would not arise.
As I already mentioned, encoders can already be attached to multiplexers, not using the multiplexer values read during the normal polling loop, but reading their own inputs directly without interference with other multiplexer operations (i.e. regular inputs), and totally with their own timing.

Using a dedicated multiplexer for encoders has no technical reason whatsoever for timing, it is just a personal preference because it is arguably more comprehensible for a novice user from a configuration or wiring standpoint.
And while it is true that there are other ways to expand "regular" inputs, it's not necessarily a good thing to limit the user's choice (which often is not arbitrary, e.g. existing installations).

It might even be argued that multiplexers can be slightly faster that shift register chains, besides being more flexible in avoiding processing latency (and not requiring as many resistors to be additionally wired); but this would require some changes to the current input polling management, so I'm not interested of making a point of it in the scope of this discussion (maybe a topic for a different modification).