Also, though I'm not an embedded systems programmer, I do have some assembly language programming experience, and one fairly decent analogy to firmware corruption is the Game Genie on the old 8-bit NES.

Each "code" you'd enter on the Game Genie alters one byte in the system's RAM or in (what the CPU sees as) the cartridge ROM. So for example, in the game program code there's some value that says every time Mario jumps, increase his Y position until it reaches, say, 50 pixes above the ground, and once it reaches that, make him fall downwards.

So you'd enter YAUVIO or whatever the heck it was, and that would translate to the hardware as "replace the value in (location) with (#)." Let's say it replaced a 50 in that spot in the jump code with 255. Then, when you played the game, you could jump all the way off the top of the screen.

Bringing it back to the Variax, I'm suspicious of the idea of firmware corruption being to blame because it's such a specific symptom (the mixing of altered and original tunings), and general firmware corruption would mean that random spots in the firmware are getting altered - like entering completely random Game Genie codes. It's unlikely that a bunch of people are getting *exactly* the same bytes in the firmware corrupted in the same way. It's more likely the Vax would simply refuse to boot, lock up in certain situations, or have some incredibly subtle error in a random model or two, such that you'd never notice it. (The equivalent of what always seemed to happen when I entered random Game Genie codes. )

My instincts tell me that there might possibly be something that sometimes happens upon initialization of new firmware that is curing/causing the problem, instead the reflash process itself. I'm not sure, of course, and the firmware corruption could still be it, but the idea tickles my brain.