In succinct form:

The problem with Solaris 10 x86's boot process is not so much that it is trying to pretend that it has OpenBoot, the problem is that it is doing such a clumsy and awkward job of faking it.

I will admit that I am not a fan of the Solaris 10 x86 boot process. I understand why it is trying very hard to pretend that it is just like SPARC hardware with OpenBoot, and I can even sympathize with Sun's motivations for this. But the contortions that Sun forces the natural x86 boot process into to do this are both painful and unnecessary.

(Yes, they are painful; also inconvenient, complex, and so on. Modifying GRUB menu entries on the fly is not a great way to do anything, plus it is nothing like an actual OpenBoot environment.)

The contortions are unnecessary because Sun is already putting a program between GRUB and the actual Solaris kernel, namely /platform/i86pc/multiboot, which even has the job of faking various bits of OpenBoot like EEPROM parameters. This makes it the perfect place to go the rest of the way and just build an OpenBoot like command line environment that would let the user interrupt the boot process to supply kernel boot arguments and so on. (GRUB would be demoted to a small implementation detail and the way to get to the built in emergency rescue environment.)

Since this is such an obvious idea, it must already have occurred to Sun. Presumably there is some good reason that they have not already done this.

(Looking at the OpenSolaris code online suggests that multiboot is already having to deal with PC hardware issues, including the console, and is not just purely playing around with stuff already in memory.)