IIRC Apple used to do something like this on their installer DVDs (back when they shipped the OS on DVDs). The Mac OS X installer was on an HFS+ volume pointed to by an Apple Partition Map (which would only be recognized by Mac OS X and the Mac's boot firmware), but the DVD also had an ISO 9660 header (that'd be recognized by Windows) pointing to Windows-compatible drivers for the Mac hardware. Completely separate volumes, with completely separate content.
Hybrid discs were common back in the CD-ROM era for games and multimedia discs. There'd be an ISO partition for PC executable installer and a Mac partition for the Mac version, and both partitions would have have pointers into a single copy of the large game data/video files that there wouldn't have been space to have 2 copies of on the disc.
The concept happened way before that too. Even though the Atari ST and Commodore Amiga had different floppy disk formats (and were bitter rivals), because they shared their main processor (MC68000) a great deal of games and software were available for both.
Occasionally, that happened on the same floppy disk, via a horrific sector format interleaving trick invented by Rob Northen (who did a lot of copy protection stuff at the time). Notably, the Future Publishing magazines ST Format and Amiga Format started out as the combined ST/Amiga Format and the "coverdisk" was exactly that - readable by both, with different files on each machine.
This reminds me that one of the filesystems that could probably be added into the polyglot is Amiga's Fast File System, as the superblock is in the middle. Rumor has it that this minimised seek times from anywhere else on the floppy, but I would think that one doesn't need to read the superblock that often.
Microsoft's FAT to NTFS conversion tool has been doing this sort of thing for years, too. It just puts the NTFS master file table and other stuff into the FAT free space, or a designated file. Of course, being a conversion tool the intent was that both sets of data structures described the same files.
Equally interesting are the tools that convert from the "MBR" style partition table to EFI partitioning. Again, this requires that the MBR-style partition table have free spaces into which the EFI partition table can be put. They have to be in fixed positions, though, unlike the NTFS MFT.
Small quibble, the original file system, named ext2_saved, is a subvolume/snapshot. As long as it's kept around, you can revert the conversion while losing any changes made to the Btrfs file system.
The comments explain the strategy in some detail. ReiserFS conversion is supported in addition to ext[234]. Because Btrfs requires only a little fixed space, just its superblocks, in theory any file system could be converted.
The difference here, though, is that NTFS does not have BTRFS's reserved area at the start of the volume. The BTRFS converter has to relocate foreign data structures out of that reserved area, meaning that the volume is not simultaneously both the old and new formats. Ironically, given what I mentioned, this conflicts most heavily with FAT.
Whereas the only fixed-position data structure in NTFS is the BPB in the Volume Boot Record, which it can even mostly share with FAT. In the FAT to NTFS conversion there is a point where (BPB aside) the two sets of filesystem structures are simultaneously valid.
Distro installation images (at least the Fedora ones) are kinda like this. There is a bunch of partitions and weird metadata in the right places, so that you can dd the image on a USB stick (or burn it to a DVD) and it will boot on any BIOS or UEFI PC and on Mac. Yes, there really is a HFS partition on the media just for this. :)
