This is a bit of a bump, but there appears to be a bit of misunderstanding in these threads as to what disk images are, unless I'm totally misreading people's statements.
Way way back, Apple created a disk image format (DiskDup+?). It took the contents of a 400 or 800Kb disk, and wrote it out to a file on a hard disk. This was the original Apple Disk Image format, and was in direct competition with third party formats on the Apple series computers like SHK (Shrinkit). The format included a wrapper that indicated the way the contents were formatted -- usually ProDOS, MFS or HFS. The contents themselves were ignored, and presented directly to the host operating system as a virtual device -- so the OS would be in charge of reading out the contents and either recognizing or not recognizing the format.
When 1.44MB disks came along, along with larger SCSI hard disks, Apple came up with a New Disk Image Format (referred to as NDIF).
NDIF was a bit smarter about how it encoded the disk data; it also included support for metadata and a disk checksum, supported arbitrary disk sizes, and had reserved space for future data use.
This reserved space came in handy, as it meant that new file system types (Joliet, High Sierra, UDF, HFS+ [all the various versions]) could be encoded with the container being able to present useful decoding information directly to the host process. So for the vast majority of "classic" Mac OS, NDIF images reigned supreme.
However, Toast came along with its own format for CD images; it was essentially the byte copy of the CD with a header on the front that included instructions on how to burn the data to the disc and append the index structure (because unlike HFS, optical disc formats write the index data at the end of the track, so that new tracks can be added to a write-only disc and the index information will still be up to date). NDIF can't dynamically support this index style.
Meanwhile, Shrinkwrap came along and chose another format, where the metadata was used to enable smart compression of the block data. This allowed for very accurate (and small) images of disks, but was not portable to different partition formats, and was not easily readable by other disk image tools.
When Apple introduced DMG-style disk images, they completely changed the container format: gone was the disk header with all the extra information; instead, this was all added to a footer, to make DMG files completely compatible with write-once-and-append read-only media. This means that starting with OS X DMGs, the actual partition data starts at byte 0, and you need to read the end of the file to find out the partition format. This can have some curious effects, especially when the first partition starts at block 0 with a ZIP file -- because the DMG then starts with a zip header, and the first file can actually be opened and manipulated by most zip applications.
Over the years, the partition formats Apple has supported in the OS have changed; first support for MFS was dropped, then support for HFS was dropped, then Apple dropped support for NDIF altogether in Disk Utility. It also stopped supporting some of the earlier esoteric versions of HFS+ as well.
Separate from all this, you've got the various optical media formats, some of which are supported by Apple, some of which aren't. ".iso" is *supposed* to refer to binary data in the ISO-9660 format, which can include HFS, High Sierra, Joliet, Red Book or even UDFv1 data. The data is written straight to file, with the track metadata being written to the end of the associated track (which can be in any of these formats).
".toast" images are essentially ISO-9660 images with a header on the front that includes instructions to Toast for how to handle the file beyond the track data included in-line.
"bin/cue" file pairs are the ISO-9660 compatible binary data paired with an external file that uses ASCII text to define the image's structure.
"img/cue/sub/ccd" file quartets are again the ISO-9660 compatible binary data paired with the external cue file, plus sub-track instructions for the burning software (to overcome some copy protection schemes) plus a "Clone CD" data file with the general instructions to tie all this together for the Windows software "Clone CD".
The big thing to notice here is that "Apple Disk Image" actually refers to three different container types, all of which support different combinations of partition layouts and formats, and are in turn supported by different combinations of Apple image tools and operating systems. You need to get the software, the operating system (with supported partition type) and the image format to all line up to be able to actually read/write/mount any given disk image.
Toast doesn't care about the partition type really, as long as it knows how to write it to disk. It passes actually mounting the partitions off to the host OS, which does the heavy lifting.
