USB automount failure implicates hald
This problem was partially investigated by Joshua M Culow. He concluded that hald or glib was broken.
I've continued the investigation, with many changes to glib that I had hoped would correct the problem. None were successful. I conclude that the fault is not with glib in isolation, but that glib is not compatible with hald in this specific situation. Changes to hald (part of illumos) may fix the problem.
The situation is that when hald detects that a USB stick is inserted, hald sends messages to itself through a pipe. It sends three separate lines, one at a time, using the write() system call. It reads them back by calling the g_io_channel_read_line() function in glib. This glib function attempts to aggregate the lines into one buffer. Within the glib function, the second read() of the pipe always gets the error EAGAIN. Consequently, the g_io_channel_read_line() function always fails, returning G_IO_STATUS_AGAIN (3).
Through investigation of glib on OI, I learned the true meaning of the EAGAIN error. In general, it is indeed a temporary read() failure. A retry of the read() may succeed. However, in the specific situation here considered, the pipe is empty, but the other end of the pipe is open for writing: all read() system calls will fail with EAGAIN. This at least is the case on illumos. Other OSes may behave differently.
Another thing I noticed is that the lines written by hald all end in "\n\0". They are the same when read back by g_io_channel_read_line(). It's possible that glib may be confused by the trailing NUL. A change to hald that avoids writing the NUL byte may be part of the solution. However, the sscanf() function does require a NUL-terminated string. The code could overwrite the newline byte to provide it.
However, the services of glib are not required to read back the line. After all, the line that is written is fully-formed and can not be aggregated. A read() system call alone will work fine. In that case, the trailing NUL can be retained.