Yes, they send you shipping confirmation when your order ships.
I sent an email to Globalscale Sales immediately after I placed my order (June 13) and got a rough estimate that my order would ship in the next few days (shortly after July 14). That estimate may be too optimistic though.
(it hasn't shipped yet)

When I emailed and asked for a rough estimate of when my plug would ship, I was told that the date was pretty much entirely dependent on the arrival of Marvell's next lot shipment of hardware. Marvell is at least making the processor, and their exact specs for the other hardware and the fact that another supplier is picking up the Sheevaplug with the same components makes me reasonably certain that pretty much all the electronic components are made by Marvell.
As to whether Marvell is to blame, I doubt they expected advanced computer users to jump on the Sheevaplug bandwagon, and that problem is further compounded by the fact that this is a new CPU design, and as these forums can show, the number of plugs that were dead on arrival or died soon after is fairly high.

Okay, then people on these forums are unclear on the concept.
GlobalScale is shipping hardware that's supplied by Marvell. They aren't shipping late because they're poorly run or because they hate customers, they're shipping late because Marvell hasn't supplied them with any parts. Any new suppliers will suffer from the same problems until Marvell manages to increase production of the hardware.
Globalscale isn't changing the date because they don't like you; they're changing the date because they don't have anything to ship you. They rely on Marvell's estimates for production dates, and apparantly those estimates haven't been working well. Demand for the Sheevaplug was far above expectations, and they're trying to keep up.

Now, their customer service may not be coping well with this, but you can't blame them for hardware shortages. Their website states quite clearly that they're filling backorders, and when that's the case, you can expect a long wait.

EDIT:
Also, a quick search of the forums reveals a number of people that received prompt service and replacements for dead Sheevaplugs and one person who said they were slow but didn't need or get a replacement.

I'm wondering whether the Sheevaplug is 32 or 64 bit. I haven't received mine yet, or I probably wouldn't need to ask this. I know it follows the ARM architecture, but I'm pretty sure this distinction still exists there.
If a programmer wants check this, in C, you would just print sizeof(void*).

Edit:
Actually, could someone just post the output of `uname -a` ? That should give enough information about the system that we can figure it out.

I'm wondering if anyone has tried to set up Bacula or another network backup suite to have the Sheevaplug host network backups. Also, does anyone have a networked backup suite they can recommend? I tried Bacula on Windows Vista, and bad things happened. It may have improved since then, though.

Ordered June 13, and I'm told that the shortage is supposed to end on July 9, but the next lot will arrive on July 13? I'm not sure what they mean there, but hopefully they'll start coming soon.

I'm considering using my Sheevaplug (ordered, not delivered) to host a USB webcam for remote access, but I'm wondering if it's powerful enough to do live video encoding. More specifically, I wonder if the lack of a hardware FPU will cripple it.
I don't recall if it's possible to get raw image data from a camera (I think it was with some, but not with others?), but I would think that the best approach would probably be to encode raw video to XVid on the fly. The lower quality approach would be to stream JPEGs (I know that's only supported by some cameras, but mine supports it).
Anyway, how would something like this go?

The kernel will not ever automount anything for you, and even the rootfs "mount" that the kernel performs at boot time will do bad things if a mount command is not executed to formally mount the root filesystem. Mounting is an operation that links a kernelspace filesystem driver to a userspace mountpoint, and it must be initiated from userspace.
As for automounting, as has been suggested, the best approach is probably to use udev and write custom rules for when a drive is connected. The kernel, as a shortcut, calls udev scripts when certain kernel events occur, and udev can automatically make the kernel event into a userspace event, whether that event is creating a folder in /media to show that a filesystem can be mounted, or, in your case, actually mounting a filesystem there. You would probably also need it to somehow notify a management application that the drive has been mounted.