We have plans to remedy the situation, but an initial implementation is half way through.
Without that first implementation, it is impossible to predict how better (or not) the situation gets. If our plan succeeds, great, otherwise we need to try other things.
To be clear on what this means, we will make way for assigning a specific device id (or device order) to a footswitch. This is mainly to fix the boot order of multiple footswitches being random, but also helps with the entire randomness of the boot operation. In order to prevent conflicts on the serial line when multiple footswitches are booted at similar times, there is an attempt at generating a random number, and use that for resolving timing conflicts. Problem is, generating a truly random number is an almost impossible task, even more for embed devices where there is no extra source of entropy to feed from.
This will fix the issue with multiple footswitches connected at the same time (or during/on boot).
The next part is slicing the list-type parameter addressings. Currently we give to each device as many items as it is possible, with a 50 item limit or 1024 bytes (along these lines anyway). This is a problem as control chain requires very precise timing, and big messages easily clog the serial line.
Solution for this is already implemented, by only passing 5 items at a time to control chain devices and have them request more data when needed (for 5 more items). Last I checked, only 1 bug remains to fix for this part to be finalized.
In terms of when this gets out, the plan is to have this by v1.13.
We have finalized the v1.12 features already and are doing the final testing, that should go out as RC1 end of next week unless we find some last minute things.