You have Missed the Biggest problem with Multiboot.

[Peter Dolding <oiaohm@bluebottle.com>]

Funny as it seams its not the how it works exactly is the problem.

Lets take Reactos for example.  Modules/drivers that must be loaded on 
boot are declared in the registry of their OS.

Where in the current Grub can this be done.  In the Config File of 
grub.  A lot of OS's need to be able alter how this information.  
Inserting into the grub config is not always able to be done.  In 
Reactos it makes live harder because one copy would be in the registry 
and one copy would be in the grub boot and would have to kept synced.   
So for them it was simpler to develop their own boot loader than use 
Multiboot.

Really what is required is a OS setup stub.

Stub returns list of modules and kernel to be used then Grub takes over 
and does the multiboot.  This is really just changing where you would 
get the information from.  Instead of the grub config file to where ever 
is best for the OS.

This is a extra feature.  Standard file system modules for grub.  So if 
I add a new OS using a different file system than currently installed 
grub I just tell grub to use file system xxxx xxxx being the location of 
the file system module.  Also passing access to a standard file system 
module threw to the stub.  Since stub should only be doing read only 
stuff and the file system module should only be read only it should not 
be a problem..

Now if we could share standard file system modules with the other open 
source boot loaders would save a double up of work.

OS developer with both parts are provided with a advantage at first they 
don't have to write file system modules in a boot code to get OS working 
only the read write file system driver of the OS.  And it should be less 
coding.

Peter Dolding