I was just doing it quick to validate that the ADC works properly before trying to optimize. It will probably end up different since this won't have very good timing accuracy, but since I couldn't get to the point where the four ADCs were simultaneously sampling I didn't bother going further. I thought this would be the easy part.
The delay shouldn't do anything, but with such strange behavior I thought it best to isolate the two parts in timing. Originally it was just measuring all four channels one after another in the main for loop, but that didn't work so I started pulling things apart to isolate the simplest instruction that would break it. The delay just proved that the read on A4 caused a persistent change to the behavior of the ADC, as opposed to some multiplexer-switching based settling issue.
With regard to defining the variable based on a function... forgive me, but I don't understand why that would be an issue. Doesn't the compiler take care of that? In any case, I have tried double reading the ADC already:
unsigned int analogvalue4 = analogRead(A0);
analogvalue4 = analogRead(A0);
and it didn't change anything. My hope with that was that reading once would switch the multiplexer and then the second read would be more stable, but this issue seems to stem from something else.
The impedance is 50 ohms for all four channels (connected to an opamp output through resistor).
I wonder if there is some bug in the Due ADC library. I might try rewriting it without using AnalogRead() and instead using the underlying registers, but that will take a little while to work through the data sheet.