The answer for "what's wrong with these floppies?" is that they're double-notched. That's needed for double-sided disks... on systems which have single-sided drives!
The PC has basically always been double-sided, so they only need one notch, on the top/a side.

here's why they shipped it on a double-notched disk anyway:
Broderbund was releasing games on a bunch of other systems that DID have single-sided drives. For simplicity they just bought Xty-thousand double-notched disks

is it gonna matter? not in the slightest (assuming there's no format-mismatching, which their shouldn't be: these are all the same density of disks, I think).

The PC doesn't check for a notch there, so it won't notice either.

It's just funny because this is, like, technically wrong?. These aren't PC disks, but the difference doesn't matter, so why not?

It probably saved them a decent amount of money because of bulk discounts and inventory simplicity.

also after all this wondering about "how many disks does Carmen Sandiego Enhanced (1990, DOS) come on?" is even sillier because I ALREADY KNEW THE ANSWER, I JUST FORGOT I KNEW IT

I am currently, as in this very thread, reverse engineering Carmen Sandiego Enhanced (1990, DOS)!

I've seen the code that asks for you to put in the other disk! And it only asks for DISK1 and DISK2!

just looking at the files, not the code (and not having seen original disk images yet that I can recall), I bet the answer is that they put CITIES.DAT on DISK2.
the whole game - cities.dat is ~300kb, with cities.dat being 168kb.

They could do the whole game - carmen.dat and cities.dat in only 200kb, which'd give them 160kb (luxury!) for a fancy installer.

This game autodetects everything (video and audio modes) and you can install it by just doing "copy A:*.* C:\CARMEN" on each disk, so I don't think they would have needed a fancy installer.

I should just check. I'm sure disk images can be tracked down in places.

the video and audio detection seems to be excellent, by the way. it just silently figures it out, without asking questions or requiring special arguments or configuration.
Perfect for a game aimed at the little childrens.

I found two different copies of the disk images, in different places.

both are imaged off a 3.5" disk version, which of course comes on only one (double density, 720kb) disk!

That version has no installer. Just the usual files (and a "DESKTOPD.CFG" file that I don't understand)

I did not realize they implemented a file browser in this program! I only found it by hiding all the DAT files from the EXE, to see if it'd ask me to put in floppies in.

So I've got code at 17DA:08AA, which is E8 5D F7. DOSBox decodes that as CALL 000A.

Manually decoding it myself, it should be a relative jump, and it's a jump to $-0x8a3. following the jump it ends up at 17DA:000A.

BUT GHIDRA thinks this code is at 1fb7:08aa, and it decodes it as call SUB_2000_fb7a, which doesn't exist.

I'm not sure how (0x08aa+3)-0x8a3 = 2000:fb7a. Something weird is going on. Why is the number BIGGER?

the +3 is because E8 5D F7 is 3 bytes, and it goes off the address of the next instruction

Ghidra even recognizes there's a function at 1fb7:000A! It's called VideoDetect

eww. They're using the NEAR version of CALL to call a FAR procedure.

You might say "wait, won't that break when it tries to do RETF?" and yes, it would, unless they manually do PUSH CS before they call it!

I think this saves one byte?
a call FAR absolute would be 5 bytes for the call, whereas push CS + call NEAR is 3+1 bytes

I might have to make a NASM test case. This could be Ghidra fucking up at decoding this one instruction

similar things in the test.com file. I moved stuff around in the memory map and it's not erroring now. I've probably created endless glitches elsewhere though

Anyway it seems it doesn't have a VideoDetect function, it's a DriverDetect function, since it's used for sound too.

First it goes through the video drivers in the following order:
VGA, TGA, EGA, HGA, HERC, and CGA.
Then it goes into the audio drivers:

stdsnd, adlib, covox, gblast, ibmg, sblast, tandy.