What's wrong with chimera?
Nothing wrong with Chimera per se, in fact. The question is some people, maybe out of vanity or OCD (like me) want to have a pure GUID disk instead of a hybrid MBR and a MBRed Windows 7/8. Chimera AFAIK was developed (based on Chameleon) to emulate UEFI on top of a BIOS system, so some could use a GUID disk (as required by a vanilla OS X installation) with BIOS (unable to boot a GUID disk). As BIOS forcibly boots from MBR's boot sector so Chimera had to be put in it.
But things aren't so simple.
The fact is Chimera is not a single beast. It's a quite complex code that can't fit in MBR's boot sector. So it's "chainloaded". The code snippet (stage 0) that exists in the MBR sector loads the real Chimera (stage 1, loaded from a partition), that in its turn detects installed systems and gives the user the option to load OS X's kernel or other OSes's boot loaders (Windows, Linux, etc.).
This stage 0/stage 1 scheme is nothing revolutionary. In fact most boot managers do exactly that (Windows Boot Manager, GRUB, GRUB2 rEFIt, rEFInd, etc.). If you create a Hackintosh install image with MBR support you can even boot OS X's kernel directly from GRUB (I did it once)
So our problem isn't Chimera's existence, but the fact that in a default Chimera installation we need a hybrid MBR so that little code snippet that loads the real Chimera can be written in MBR's boot sector, and in this scheme to load Chimera you need to boot in BIOS mode. The mistery is how to load Chimera's stage 1 without having an MBR-based stage 0.
That said, Chimera's install package is a compressed archive with lots of things inside, including a file with stage 0 and another with stage 1. And there are HOWTOs out there explaining how to manually put stage 1 in the EFI partition and other tricks. But an easy, automated, click-next-click way to do so isn't available yet. And it's the root of the problem.
In a pure UEFI system with a GUID partition table (GPT) there's no such a thing as a a disk's boot sector ala MBR. Things work quite differently.
In an UEFI system with a GUID partition table (GPT) you'll find a EFI partition that is in fact a FAT32 one (maybe that's the reason you can't use a Windows 7/8 UEFI boot media to install it on a FAT32 partition) and inside of it every UEFI-aware OS will store its own boot manager (stage 0 and some will install stage 1 too, if any) into a folder structure. The firmware stores in the computer's EEPROM the information about what boot managers are available and which one must be called. As the limit for the size of the boot manager is the size of the EFI partition, the 512-byte limit for stage 0 on MBR doesn't exist anymore (and doesn't make sense at all). But an UEFI boot manager is not a sector on disk that must be loaded to a fixed memory address and be executed. It is, in fact a program.
An UEFI boot manager is a 64-bit (in most cases) program in its own right, and as a proper program it is stored in the partition using an industry-standard format: the Windows(!?!) Portable Executable (WinPE) format. To create and compile it of course you'll have to have the UEFI SDK (not available on Mac/Hackintosh AFAICT). And not only that (already daunting task), but the actual knowledge about how to register the boot manager in the UEFI firmware.
So we need one of the following:
1. An UEFI-compatible stage 0 to load the current Chimera;
2. Another UEFI boot manager to chainload Chimera in an easy way;
3. An UEFI-native Chimera port;
4. Another UEFI boot manager capable of loading the Mach kernel.
Alternative 1 is the easier IMO, but alternatives 1 and 3 involve using an UEFI SDK for development, something that AFAIK isn't available for Mac (I may be proven wrong). Alternatives 2 and 4 already exist, but they aren't user-friendly at all. Alternative 3 may be simple or radically difficult, I don't have means to evaluate right now. Now we need someone willing and able to implement one of them. I'm a C and C++ programmer, but I'm just starting to take on OS X. Maybe MacMan can help.
