That fix is indeed a firmware upgrade. It's clock-related, and it only affects the 42MHz version. With the multiplication factor of 3 and lots of noise on the supply lines, the memory controller locks up in an unknown state at some point. This is indeed a digital thing, and it can be fixed in the firmware.
However, while I still think it has a connection to the "graphics errors" effect, it's not the solution yet. Remember that the 0MB-fastmem-effect is only affecting the 42MHz cards. On both the 28MHz and 56MHz cards, the PLL runs at 4x speed where it's obviously more immune against noise. However, the "gfx errors" problem affects all three models.
I'm on it, and it seems that I have a combination that actually shows the effect now. It's a board that AmigaKit has sent to me, combined with one of the power supplies that Vesalia sent to me. I'm currently working out a procedure to *force* the effect, and once I have that, I can hopefully program the logic analyzer to record what's happening, so I can see what's going on.
Another issue that came up this weekend is the MMU functions of WHDload (MMU tooltype). I may be able to solve this by violating the Motorola datasheet and give a proper termination even to "unknown/reserved" function codes. It's not directly MMU-related, but the MMU-tooltype of WHDload uses those unknown/reserved function codes for "something" (don't know exactly what), and since they are not documented, my hardware does not terminate such accesses, trying to be as close to "the book" as possible.