I'm looking through the scanned manual for the cabinet, and it lists the monitor a dual-sync, so it sounds like it's not either/or, it's both.
I remember the wiring harness only had red, green, blue, sync, and ground going to the monitor. The scanned document indicates a 10 position connector that I don't remember seeing, with a full complement of sync signals, but still only red, green and blue (no intensity).
The CGA standard includes red, green, blue and intensity (common to all colors), plus ground and a pair of sync lines (one for horizontal, one for vertical). Being a digital RGBI with only 4 signals, you end up with a limit of 16 colors. It also has a horizontal scan rate of 15.75KHz, which is extremely close to the 15KHz listed as the lower of the two scan rates supported by the monitor.
The EGA standard includes red, green, blue, separate intensity lines for each of the colors, adding up to 6 signals giving the 64 colors that EGA is capable of. It also calls for a separate horizontal and vertical sync signal. EGA has multiple resolutions with different scan rates. The 200 line resolutions are run at 15.7KHz (just like CGA), while the 350 line resolutions are run at a 21.8KHz horizontal scan rate. This is lower spec than the 25KHz listed as the higher rate supported by the monitor, which leads me to believe that this actually supports a non-standard "enhanced EGA" resolution that was actually somewhat popular with aftermarket cards, with a 400 line image.
With all of this in mind, I'm led to believe that the "CGA/EGA" listed in the manual is not a signal specification, but actually is an approximation of the monitor's resolution capacity. With only 3 color lines, if digital, the monitor could only handle 8 colors, which is below spec for even CGA (much less EGA).
I'm seriously wondering if this monitor is in fact an unbalanced analog RGB monitor with a composite sync (horizontal and vertical sync on the same line).
Here's an example of a circuit capable of converting VGA to RGB+sync:
Apparently there used to be an extremely cheap (like $1.50) VGA to Mac monitor adapter that would work for this (~a decade ago), but I haven't been able to find one.
As I'm writing this reply, I stumbled across a site with loads of interesting information on using non-VGA analog RGB monitors.
Unfortunately, I didn't find any cheap solutions for our problem, but did have good info that might help us connect old consoles to this monitor. I only skimmed through the site, so may have missed something valuable. I encourage others to take a peek.
It looks like the best solution might be an HDMI-to-VGA converter (I think I've seen 'em well under $20), plus the previously mentioned DIY circuit, combined with custom modelines to force compatible resolutions.
The main problem with that is, during bootup, before launching X, the default (text screen) VGA resolution (and more importantly, 31KHz timings) will be in use. This can overdrive the monitor, so we'd need to either filter those out, or have the monitor off during bootup.
* It might also be possible to switch the Raspberry Pi to use a serial console and keep the HDMI off until X starts (I've not tried this yet). This would solve the overdrive problem.
I was just thinking about the 6MHz bandwidth spec, and at first that seemed a little odd since it would restrict us to a CGA resolution of 320x240, but then I realized that is only for progressive scan modes (and this is capable of both 50hz and 60hz refresh rates). With that in mind, we may be able to drive a bit higher resolutions in interlaced modes.
We should list out the games we plan to load onto this system, to see if we need a resolution greater than 320x240... if not, this may just work for us. If we need something higher (and interlaced is acceptable, it still may work
Edit: 6MHz is also the bandwidth of NTSC, which is what made me realize that interlaced modes are likely a higher resolution possibility at the same bandwidth.
Edit 2: I also found this VGA adapter for the Raspberry Pi. It's open hardware so we could build it ourselves. I don't know how it works with X (for custom modelines), but I do know that it is effectively a secondary display, so will not produce a signal until it is instructed to do so. This solves the overdrive problem.
Edit 3 (I should stop...): I found someone else who went through the same research.