that's quite interesting, and i suspect you've discovered a bug.
actually two bugs, maybe. one has to deal with drawing alpha-blended
images, the other with drawing using RGBA32...

the simplest way to trigger the second bug, which may or may not be
related to the first, is to draw using black, RGBA32 channel and full
alpha:

the following draws fine on the screen:
b = allocimage(display, Rect(0, 0, Dx(screen->r), Dy(screen->r)),
ARGB32, 0, DBlack);
draw(screen, screen->r, b, nil, ZP);

but the following draws incorrectly as blue:
allocimage(display, Rect(0, 0, Dx(screen->r), Dy(screen->r)), RGBA32,
0, DBlack);
draw(screen, screen->r, b, nil, ZP);

at this point i would suspect an endianness issue. setalpha doesn't
care about endianness, but libmemdraw does.

to add a bit more information i've taken the liberty of modifying your
program. the code attached exhibits all sorts of issues with alpha
blending and illustrates them more fully (i've also used a few of the
tricks in /sys/src/libdraw/arith.c to show the correct usage of Pt(),
ZP, color names and the like)

in this example everything is drawn over a black screen image to avoid
any effects of conversion to the real bpp of the screen. the base
image's channel type is fixed at ABGR32 because this particular
channel does not exhibit the behaviour of switching from black to blue
described at the beginning of this email. i've included a screencap
with the black image using RGBA32 so you can see the difference.

the program shows 4 different columns of 256 lines with varying levels
of alpha-blendedness (from 0xFF on top to 0x00 on bottom). the first
column draws white, second red, third green and fourth blue.

below the column a single line is drawn twice: once on the black
screen and once on the display screen directly. in the two attached
snapshots the line (created with ARGB23) is drawn correctly both on
the black image and on the display when the black image is ARGB32, but
if we switch to RGBA32 for the black image the first line gets mangled
when the whole image is displayed.

i'll leave the bit/byte swap analysis to the readers :)

ps: are you using this on native terminal? it would be very
interesting to test the program there for different values of ARGB32,
RGBA32 and ABGR32 (there's no BGRA32) and possibly under display depth
of 32bpp. i only have 9vx and drawterm to test with, unfortunately,
although i will try with osx's drawterm when i get home: that one runs
in 32bpp at all times.

cheers!