How would you define an applicable ruleset in a scenario where multiple PDS cards are stacked on top of each other,
Unsupported
In practice, stackable cards tend to have switches to choose the slot/irq. It's not very clean nor macintosh-like, but it worked. Apple only ever intended for one card to be used; I suspect in the SE/30 the idea was that a single card could have multiple functions in multiple slots, and perhaps the vendor could sell variants with different subsets of functions by simply not populating some components... but without needing to rewire anything. One PCB fits all
In practice, as long as you card can "play nice" by letting the user pick the slot(s), then it's OK. The actual mechanism is up to the card's designer. It's unsupported anyway... That's for PDS ; for NuBus obeying the rules is more important, as all 6 slots could be populated in a II/IIx/IIfx.
The SE/30 is obviously a special case, since it always has its internal video circuit, which makes me wonder, how the synchronisation is handled in case of 2 screens. I would assume that the "master display" is the source of synchronisation, correct?
As far as I understand how it works, each screen is independent and there is no real "master screen". Any one screen can become the screen carrying the primary menu bar/boot screen, but hardware-wise they are all equal. Each device generates its own interrupt at whatever frequency, and the system software handles everything.
Most later Macs had internal video and additional slots, and earlier ones had multiple slots and were supposed to accept multiple cards from multiple vendors running with different vertical refresh...
I'm talking about custom resulutions, with user definable parameters
OK, so yes you can put that wherever you want as that's a device-specific function. The system only needs to know which resolution was picked, not the implementation details. So all good.
You mean games which (...)
Any and/or all of that, plus games (or other applications that were badly written or just wanted speed at all cost) that bypass some of Apple's mechanism to access the FB more or less directly or doing weird things. Some of them are gonna break no matter what (early B&W games would address the B&W by hardwiring the address, that didn't work on any non-compact Mac).
Which brings me to another question, what purpose do off-screen surface buffers serve in MacOS?
Mostly "clean" refresh (update the off-screen buffer, then blit it on-screen in one go). Usually, they are in main memory, I think, but don't take my word for it; others here are more expert than me on exploiting QD in applications. Some accelerated card had (often optional) off-screen memory, so that's also doable, but I have no idea how much SW is needed to implement the functionality.
The legendary 8*24GC accelerated device was offloading all of QD to its integrated CPU (some AM29000 IIRC), but any misbehaving application would have display issue, and Apple didn't support them in many version of the system software. Too much SW efforts.
I suppose that this can be much simpler on the SE/30. The problem seems clearly that there is no defined ruleset for multiple cards sharing one slot.
The theory is, as long as everyone uses a different (pseudo-)slot, all will be fine, but the SE/30 (or any PDS) wasn't designed for this so doesn't have a "clean" mechanism for like for NuBus.
PDS are hacks, essentially
But not on the SE/30, since the only applicable clock is 15.67MHz, right?
The PDS also has other clocks, but yes the bus clock is the ~16 MHz one (15.67 sounds correct, but Apple was claiming 16, any companies did that kind of "rounding") that must be used for synchronous bus transaction (/STERM), you can get away with using another clock if you want to deal with the timing requirements of the asynchronous stuff (/DSACK[1..0]). The same pin has the 20 MHz clock on the IIsi. It's not a clock on the IIfx, because Apple... its 20MHz clock (half the real system clock) is on a different pin. The IIfx PDS is almost, but not quite, the same as the IIsi & SE/30. The cache slot in the IIci is completely different, but physically identical, presumably so people would blow up their Macs more easily :-( (let's always call it "cache slot" and not the P-acronym to avoid confusion, and it doesn't have an IRQ signal at all so is useless for framebuffers).
Also, just for giggles, if you want to do DMA (e.g. to do main-memory to FB-memory blitting), then the SE/30 memory controller answers asynchronously via /DSACK[1..0] (same than older systems going back the II with a MC68020), but the IIsi memory controller answers synchronously with /STERM (same as the IIci and later IIRC). Progress, but not super convenient for device developer!
