For gedanken purposes, the problem space is this, on a BIOS PC.
* There can be almost any amount of disks attached to the system.
* The user can choose to 'boot from' - that is, initiate the boot sequence using whatever is in the MBR of - any one of those disks on any given boot.
* What is on any of those disks and what is in the MBR of any of those disks can change without any warning to you if you are a single OS on the system.
* Any of the MBR-based bootloaders can, and may, chainload another bootloader located in the header of any partition on any disk in the system.
* Any bootloader on the system (MBR or partition) can attempt to directly boot any other OS installed on the system (including any kernel pair that has ever existed, potentially, for any Linux install present).
* There is absolutely no de jure or de facto standard or even best practice for configuring multiboot. Different sysadmins and OSes can and will have things set up via shared bootloaders, or chainloading, or any other way in any given system.
So...yeah. That's your problem space. Migraine commencing in...3...2...1...
The UEFI design is at least theoretically miles, miles better than this. The design is that a list of 'things that can be booted' is maintained by the system firmware, and *only* by the system firmware. If you are an OS, at install time, you register yourself in the firmware's boot menu, with an entry which tells the firmware what your OS is called and what second-stage bootloader it should call when the user chooses to boot you. You install your second-stage bootloader (in a fairly standardized way) and configure it to handle _only_ booting yourself. You do not attempt to deal in any way at all with booting any other operating system, you leave that up to the firmware and the OS in question. It's a far better design. I dream of a future where everyone's finally adopted it and I can forget all the hideous knowledge I've built up about BIOS-based booting...