With all due respect, Steve, I fear that you are never going to solve
this/these bug(s) unless you are more critical of your own reasoning.
Whilst I now use computers primarily for email and word processing,
you can see from my web page that I was a computer science lecturer and
have taught reasoned programming, based on methods due to Floyd, Hoare
and Dijkstra.

Correctness of a program depends on a clear statement of what you intend
it to do, and on correctness of the parts.   This is expressed by means
of pre-, post- and mid-conditions, and by invariants for loops and data
structures.  It seems to me that these are missing here, and in particular
the implementation
   CONFLATES FAILURE TO CREATE THE INITRAMFS WITH THE INTENDED ABSENCE
that you claim is legitimate.

Let me work backwards from the headline problem, namely failure to boot
after a new Ubiquity installation.   The precondition for booting is to
have a valid (kernel,initramfs) pair.  Ubiquity, and in particular
update-grub, failed to satisfy this as their post-condition.   The
pre-condition for update-grub is that each kernel be accompanied by any
initramfs that it needs; update-grub works according to the presence or
absence of files whose names match certain patterns.  It assumes that
the absence of an initramfs indicates that none is needed.  This assumption
is wrong.

> the entire problem is that update-grub is being called (for a reason
> that I presume is legitimate) before the kernel postinst has a chance
> to do its job, and then kernel package installation is somehow failing
> to call update-grub afterwards. So the only reliable point at which
> we would generate the dummy initramfs is the same point at which
> we generate the real one.

So we come to the data invariant.  menu.lst is a representation of a data
structure consisting of a list (with a preference order defined by the
version numbers) of (kernel,initramfs) pairs.   This is obtained from 
the representation in the filesystem, which is in turn modified by the
programs that install kernels and generate initramfses.

THESE PROGRAMS ARE NOT MAINTAINING THE DATA INVARIANT.

You need to treat them as a single operation, and not two.  Or, given
that the data structure is encoded using filenames, they should be given
temporary names and then renamed by a program that first verifies that
both are valid, before putting them both in place at the same time.

You claim that a kernel can legimately do without an initramfs.  I know
next to nothing about kernels, and acknowledge that you may be right,
but I suggest that you examine that claim very carefully.   Presumably
it pertains to a multi-boot situation, given that the choice of the
Linux kernel in Ubuntu is under the control of the Ubuntu design.  This
means that non-initramfs kernels come from somewhere else, not the program
that instals the normal Ubuntu Linux kernel.  So you can adjust the data
invariant and the way that you maintain it accordingly.

Given the severity of the consequences, I, like Micheal, ALSO think that
there should be a subsequent check and fix in Ubiquity before it finishes
the installation.

Finally, there is the Ubuntu philosophy.  As I understand it, the word
means "I am here because of everyone else".   The whole open source world
relies on the cooperation of users, both for good will and for information.

With regard to reporting bugs in Launchpad, you have now said both
> The 'perfect' way is to make sure duplicate bug reports are never filed.
and
> The ubiquity bug really should have been opened as a separate bug report.

No database implementation can achieve this, except for the empty database.
Mathematically, it depends on "decidable equality" of records, but saying
whether one bug manifestation is the same as another is subjective.  
Usually, I have failed to report bugs at all because I cannot see my way
through the morass of entries in Lauchpad.  For those of you on the receiving
end of the reports, you must either indulge ignorant users like me, or
just not get my reports.

Also, for me to submit a report that is diagnostically useful to you,
your programs must first provide me with the diagnostic information,
and then tell me politely where to submit it.   This comes back to the
formulation and verification of correctness conditions in the program.