I was under the impression that next to no games other than stuff in QBasic actually used the VGA default palette, or at least large portions of it, but I'm seeing some unusual behavior that's making me suspect that's the case.

During my tweaking and testing of several different 386, 386SX, and 486 boards (and probably also with some 286 boards) I noticed a few old benchmark programs switching the display into monochrome mode (and ending up with monochrome display when going back to the DOS Shell). Getting some programs to crash, especially when in protected mode (and sometimes not crash, but run fine and just do this when closing/exiting to DOS) the same thing happens with the display switched into monochrome mode.

Then, if I run some software using 256 color VGA modes and exit back to the DOS shell, it ends up in multi-shade grayscale instead of 1-bit monochrome. Additionally, many 256 color programs (particularly those using mode 13h, ie MCGA mode) will also display in grayscale but some others won't and any using unchained 8bpp modes are in normal color.

3DBench for example, is grayscale, but PCPlayer (even in 320x200) is full color.

Further, Jazz Jackrabbit's intro and menu sections are all grayscale, but in-game is full color. Doom has normal colors, as does Terminal Velocity.

So I initially just assumed that some VGA registers got set up in a grayscale (monochrome/grayscale VGA monitor compatibility) mode that got overridden with video modes outside of the standard BIOS selection, but that's where it gets weirder:

Games that should be running entirely in mode 13h (ones that are fully MCGA compatible) like X-Wing and Tie Fighter (both floppy disk versions) show the intros and concourse sections in their normal 256 color palettes, but when you enter the 3D flight sim engine they're grayscale again.

And with that I could assume that whatever monochrome register setting is getting used just gets set some of the time (maybe depending on BIOS calls used), except it's not actually monochrome output: the engine glow color cycling in tie fighter is in color while everything else (including the esc options/setting menu) are all grayscale. So it's not just outputting grayscale by outputting a common intensity signal to the 3 analog RGB lines but actually setting the palette entries (CRAM entries) to shades of gray.

Wing Commander and Wing Commander 2 show up in gray scale for intro/menu as well as the lounge/barracks/breifing/etc screens, cutscenes, and in-game flying sections, except the background color is still the normal saturated dark blue color rather than gray or black.

Now, I can only think of 2 possibilities for this behavior: there's a monochrome register set somewhere that's readable to the system and can be polled for status and software that checks for that switches into a monochrome compatibility mode with grayscale optimized palette. (this seems semi-plausible except it really doesn't explain the mix of behavior I'm seeing and doesn't really make sense for the way it shows up in X-Wing and Tie Fighter especially)

And 2: the software and portions of games that show up grayscale are using the default VGA palette and end up loading grayscale shades that match the equivalent color shades in the default palette (presumably weighted RGB equivalents mapped to the 64 shades of gray VGA supports) and the limited color seen in Tie Fighter and Wing Commander is due to just one (or a select few) palette entries being rewritten while the rest remain set to the defaults. (in Tie Fighter both the blue and red/orange color cycling works for engine glow while everything else is grayscale)

Now, I say the games must be using the default palette in the first place (or writing grayscale palette entries intentionally themselves) because the grayscale colors look right, they look like the proper shades to match their color counterparts. So it can't just be the video card forcing things to a BIOS palette/color setting that overrides an application-specific palette since there should be wrong/mismatched looking shades and not correct looking ones.

I searched around for info on this to see if anyone had compared the palette data to the VGA default palette, but didn't come up with anything and haven't analyzed things further myself. (screengrabs from DOSBOS and something like irfanview might be useful for that other than extracting the palette data itself ... or maybe some DOS games and benchmarks allow the printscreen function in windows to work, but I think that normally only works for windowed DOS shell stuff)

To get the same behavior in DOSBox, I'd think the same benchmark programs would do the trick, but I need to document which ones those actually are. (I don't think any in Phil's DOS Benchmark pack version 1.4 does this, but some in the older 1.1 DOS benchmark compilation does, I think, and some in the 286 BenchXT compilation seem to as well)

Perhaps also worth noting:
the examples that manifest grayscale VGA mode 13h are all currently realmode benchmarks or games. (Tie Fighter requires some 386 instructions but runs in real mode or virtual 8086 mode and uses base + expanded memory, no extended memory; I believe the CD-ROM version of Tie Fighter switched to a protected mode engine and uses the DOS/4G extender)