There were two others (as far as I can tell) that reported the same or
a similar problem earlier, but a lot of other users on the news group
cannot confirm the bug.

Confirmations: 

http://groups.google.com/groups?selm=3B29C10F.C86C2C79%40unine.ch

http://groups.google.com/groups?selm=4g598uccc9iiuk5d3rn6uj24hlsovbum52%404ax.com

Seems I have tracked down the bug to
plug-ins/common/png.c:respin_cmap() which behaves differently
with a palette of 256 colors than it behaves with < 256 colors.

Your example image http://xultekh.net.nz/gimp/next.png has a
palette of 256 colors, but it uses only 5 of them.

When converting the image to RGB and back, GIMP optimizes the
useless colors away, creating free space in the palette
respin_cmap() uses to do things i don't understand but seem
to be needed for indexed-alpha PNGs (???)

I'd like to add Nick to the CC list because we need some more
info from Mr. PNG himself here :-)

Unfortunately, bugzilla is not very helpful in finding
people's account names...

I added Nick to the CC list.  Note to Mitch: you could have seen his
e-mail address by reading the message that I posted on the gimp-dev
list on the 10th of April, titled "Suggestion: add Bugzilla contact
info in PLUGIN_MAINTAINERS".  This reminds me that I still have to
post a follow-up to that message and update the PLUGIN_MAINTAINERS
file...

respin_cmap() converts GIMP's world view (indexed color and
transparency are unrelated, and transparency is binary) to PNG's world
view (indices point to a color AND transparency, transparency is 8
bit) by inserting an additional entry into the colormap which is a
placeholder for transparent pixels, much like GIF.

PNG can do better than this(*) and maybe one day I will write support
for a live web-optimiser preview and 5x5x5x2 hypercuboid RGBA palettes
and all sorts of other lovely features, but GIMP makes this sort of
thing harder that it should, for now anyway, and I don't find time.

It's worth pointing out once again that no file formats map cleanly
onto the Gimp INDEXEDA mode, and IMHO it should die a quick death.

Obviously when a GIMP image has mode INDEXEDA, and has a 256 color
palette (which is strongly discouraged for transparent images) it's
impossible to re-arrange things without basically pasting the entire
image mode conversion software inside PNG. So right now the PNG
plug-in gives up and throws away the transparency.

Perhaps instead we should try to spot this before Export and tell the
Export engine to convert the image to RGBA if it has too many palette
entries to cope with normally. Is that acceptable (the result is a
somewhat larger file size but visually correct image) ? I can probably
write a patch to do this now that I've actually thought of it.

(*) Well, it can in everything except the world's most popular web
browser, IE for Windows, which can't do transparency. Sigh.

> It's worth pointing out once again that no file formats map cleanly
> onto the Gimp INDEXEDA mode, and IMHO it should die a quick death.

Well, there are several file formats that map (almost) cleanly onto
the INDEXEDA mode.  GIF is the most obvious candidate, but some
internal masked bitmap formats used by several old games are also
very close to the INDEXEDA mode.

> Perhaps instead we should try to spot this before Export and tell
> the Export engine to convert the image to RGBA if it has too many
> palette entries to cope with normally. Is that acceptable (the
> result is a somewhat larger file size but visually correct image) ?

No, that would be annoying because the reason to use INDEXED mode
(with or withoug alpha) is usually to reduce the size of the file.
It would be much better IMHO to change gimp_export_image() so that it
can detect if the number of palette entries (+ 1 if there is an alpha
channel) is larger than 256.  If yes, then it should simply call
gimp_image_convert_rgb() followed by export_convert_indexed().  This
two-step conversion would ensure that the final image is still indexed
and that it has less than 256 palette entries.

We can add this test for all indexed file formats, or only for those
that cannot handle more than 256 colors.  In the latter case, we could
add a new constant GIMP_EXPORT_CAN_HANDLE_LARGE_INDEXED to control if
the size of the palette should be checked or not.  I do not know if
any file format would support that for the moment, but it would be
nice to allow that.

I could work on a patch that does that (I already had fun with the
Export dialog while dealing with bug #51114 so I have some experience
with that code).  But I would like to know if you think that it would
be an appropriate solution.  Opinions?

Isn't this a duplicate of bug #55700?

In which case, I checked in a fix for this in both branches in
October/November. 

Marking as a duplicate - if it isn't could somepne please explain why?

Cheers,
Dave.

*** This bug has been marked as a duplicate of 55700 ***

The fix for bug #55700 is part of the stable release 1.2.4.  Closing
this bug.