The copy of this game I have is approximately 470kb! You could fit this on ONE disk!

ARG, they mislabeled this.
Admittedly, this isn't really their fault, this is confusing shit.

This is the 1992 Where in the World Is Carmen Sandiego? Deluxe, not the 1990 Where in the World Is Carmen Sandiego? Enhanced.

okay I finally found a boxed copy of the Enhanced 1990 DOS edition. (confusingly labeled the 1993 edition)

It comes on two 5.25" disks: presumably double-density, so that's 720kb in total.

Floppy Disk Pop Quiz: What's weird about these floppies, specifically given that this is MS-DOS version?

I happened to look at mobygames, and noticed two interesting things.

First, the Mac version is very similar to the DOS version, other than the expected changes you'd get from it being on a monochrome system with a GUI.

But wow, that's a completely different font! Is that built into macs or something? (EDIT: @amr confirms it is)

(also, the dialogue box is top-aligned. DOS bottom-aligns them)

Secondly, the TurboGrafx-16 version didn't even THINK about using the same GUI!

I don't want to go through a million platforms but all the other ports of this game tweaked some art here and there or put in different location-photos, but all of them have the same basic tall-window-on-the-left, smaller-window-in-the-top-right, four-buttons-in-lower-right design

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