I'm looking for an alternative boot loader (for hard drive) to get away from GRUB and LILO. I want something that is not bloated like GRUB and does not require rebuilding a table of block numbers like LILO. Something simple and basic ... like a boot loader should be.

You might want to check out the syslinux package.

Syslinux requires a FAT filesystem. I won't have that. Maybe extlinux will work? I hope it understand GPT partitions.

Extlinux is part of the Syslinux-project.

Is there a way to bypass the "extlinux" installer command and put the bootloader image directly onto some sectors, either outside any partition, or within a partition dedicated to that image?

I'm trying to keep it all super simple ... a bootloader than just loads a kernel (an initrd image is a plus). The bootloader will be installed first. The filesystem with the kernel will be installed later and there is no opportunity to run an "extlinux" command since no system will be up when this is happening. If extlinux is a two part thing like GRUB legacy was, then I can include a 2nd stage inside the filesystem being populated afterwards. But it still can't run a command so it depends on the part that lives outside the filesystem to know how to find and read files in the filesystem.

Having the bootloader live in its own partition is an option but GPT support is a must to do this due to other requirements (all the MBR primary partitions are used up for other things). If extlinux cannot do GPT, then its filesystem-reading parts will have to live outside a partition.

The wiki is very short on specifics. The way a simple boot loader SHOULD work would be:

for MBR, the MBR sector has the 1st stage, which looks at a specific sector number hard coded in that stage to find the 2nd stage. The 2nd stage would have support to find partitions and files in filesystems (support for ext2 is sufficient at this point ... FAT is not).

for GPT, the 1st stage would read the GPT table to find the 2nd stage which resides in its own partition (1 of 128). Which partition is yet to be determined. Once that 2nd stage is loaded, it will find partitions and files in filesystems as above, though doing so with GPT. Again, ext2 support is sufficient.

For either of these, the 1st and 2nd stage images should simply be FILES that can be dd'd to the right place (but in fact, I will be integrating them into a larger image that will be dd'd in whole to the drive). If there is a command needed to "install" the images, there needs to be options on the command to store the images in files as an alternative.

I tried the GAG bootloader briefly a few years ago to multiboot, it seemed OK.
http://gag.sourceforge.net/

Maybe Plop can help.

Define "bloated". Anyone playing with gpt disks shouldn't be worried about disk space.
grub2 with gpt requires a separate partition for its core.img. All that should allow you to dd partition images in elsewhere I would think. Haven't tried it though.