die Arrays hin- und her schicken hat sowohl remote-control als auch Portexpander- (Telemetrie-) Zwecke. Zum einen sollen vom Raspi aus Encodermotoren gesteuert werden, zum anderen sollen möglichst schnell (auch zum Update der Fernsteuerung) alle möglichen Sensoren auf dem Slave ausgelesen werden.
32 Bytes sind dazu mehr als knapp, besser wären mindestens 64, gerade weil Encoderwerte 32 bit lang sind.
Auch Werte von i2c- oder UART-Sensoren auf dem Arduino sollen an den Raspi übermittelt werden können, die oft floats sind (also ebenfalls 32 bit).
Der Fall, dass nur 1 Byte im Array geändert wird, wird also fast nie vorkommen.

Wenn es keine Möglichkeit gibt, den I2C buffer vom Raspi auf 64 Bytes zu erhöhen, müssen sich 2 Arduino-Boards die Arbeit teilen. Allerdings scheidet dann der Mega komplett aus, da er ja bereits jetzt am Bus über 3mA per Pegelwandler gegen die 5V Pullups ziehen muss, und 3mA ist die Höchstgrenze für SDA/SCL laut I2C-specs. Und weitere i2c-Geräte kommen ja sowieso noch hinzu (zum Glück aber nicht mehr als hundert)

Ich komme daher immer mehr zu der Überzeugung, dass die AVRs zur Zeit eine Sackgasse sind, wegen clock-stretching, und speziell auch der Mega wegen seiner zusätzlichen Pullups.

Das bedeutet allerdings dann: nur DUEs werden zur Zeit Sinn machen, da nichts anderes funktioniert.

Oder, wie Gordon Henderson (Autor der wiringPi libs) schrieb, nur eins macht Sinn für die AVRs: "... a newer version of the kernel driver.. So one day..."

Trotzdem bin ich natürlich auf deine pigpio-Versuche gespannt, insbesondere mit mehreren Geräten am selben Bus.