Good question. You're right the problem might be something else entirely. I only suggested this explanation since it seems to fit the clues, especially the metal probe touching /NUBUS temporarily fixing the problem. And also because if the Reloaded PCB is identical to the original PCB from a schematic and netlist standpoint, and all the parts are the same too, then this would seem to be the only explanation left.
As for why it would only affect this one signal, I would suggest thinking of it differently. These kinds of problems with coupling and cross-talk are
always there, on every PCB and on every trace. But most of the time they're small enough that they don't make any difference. The voltage on a trace can bounce and wiggle a little, and it won't disturb anything until the wiggle becomes large enough to fool another chip into thinking it's a clock edge, or to make a logical 0 briefly appear to be a logical 1.
If you wanted to intentionally force a problem like this to happen, you could make a long straight PCB trace, with a second PCB trace running directly next to it for a long distance. Then on the first trace, send a signal with a sharp rising or falling edge, and observe a faint echo on the second trace. Even better, have many parallel traces whose signals all rise or fall simultaneously, like you'd have with a data bus rapidly changing from 00000000 to 11111111. This will make the problem even more severe.
When I was designing the Yellowstone disk controller card for Apple II, I got stuck for a long time on a problem very similar to this. Whenever the card would change from driving 00000000 to driving 11111111 onto the 8-bit bus, it would cause terrible problems and often resulted in the computer crashing. You can see some of the oscilloscope captures here:
https://www.bigmessowires.com/2021/06/19/yellowstone-glitch-part-6-this-is-getting-ridiciulous/ I eventually solved it two different ways. One was a firmware change to avoid changing too many output signals at the same instant. The other was the addition of small value series resistors in the signal traces, so the voltage changes would be less abrupt.
Of course this is all merely speculation unless we see some oscilloscope captures from an SE/30 Reloaded board. But my theory is there may be an issue like this with the /NUBUS signal, or a signal adjacent to /NUBUS, or a signal that's logically derived from it or that's used to derive it. And it's caused by minor-seeming differences in the way those signals are routed on the PCB, and it's not only /NUBUS that's affected but it's where the issue is severe enough to be noticed right now.
Another related possibility is that there's a design flaw in some combinatorial logic on the SE/30 board (you mentioned a PAL?), where it implicitly assumes that input signals will change in a particular order, else an output glitch may occur. Basically a combinatorial hazard. And on the original SE/30 board this requirement might be accidentally satisfied simply due to the PCB routing and differing parasitic capacitances on different traces, so that Apple's hardware designers never encountered it. But on a PCB with a different topology it might suddenly become an issue.
Adding a small amount of additional capacitance to a trace will slow down the signal, which might help. Adding a series resistor will have a similar effect, since the speed of signal change is related to the RC time constant. Adding a pull-up or pull-down resistor will bias the signal more towards 5V or GND, and may increase the signal switching time in one direction but decrease it in another. I probably wouldn't expect it to help with a problem like this, but it's worth trying.
Apologies for the long train of conjecture here, without much evidence to back it up. I'll be curious to see what can be learned from more testing. These kinds of problems can be maddeningly difficult to debug.
