In my view, auto-mounting is inherently more complex than has been addressed, and the current handling is flawed, more so in Karmic compared to previous versions (or to Fedora 11, which also uses DeviceKit).

Due to the challenges, this comment is longish.  To avoid burying an important point, I'll state it up front, rather than at the end.

*****
As challenging as the auto-mounting problem is, one policy would be really useful, and would allow us to separate out the complex cases from the common one.  But how would you express and implement a policy that if there is a SINGLE partition, auto-mount IT; if there are MULTIPLE partitions, auto-mount NONE?
*****

As for auto-mounting issues, David Zeuthen explained elsewhere that "Nautilus doesn't treat non-removable different from removable when it comes to mounting file systems. [If] there's a mountable filesystem on a device, it is mounted. If you don't like automounting, turn it off in Nautilus."

ON or OFF is a pretty coarse-grained situation.  :-)  Users may start up with internal drives and external drives, or not, at any given instance, and want different policies.  OK, so let's use /etc/fstab?  How do you describe an entry in /etc/fstab to ignore a partition without having to describe details about it, such as UUID and file system that could change?.

Let's make it even more fun.    David explained the behavior that I have seen related to differential treatment of the same drive depending on whether it is attached via eSATA or USB, "authorization is different depending on whether the device is considered system-internal or not."  So for the SAME partition, we now have different interpretations for auto-mounting, depending on connector, despite the fact that it is removable and hot-pluggable in all cases.

Now lets consider scenarios from my own systems:

  A) An internal drive has multiple distro partitions and shared partitions.  I only want the partitions I explicitly state that I want mounted.  Karmic now tries to mount everything if auto-mounting is not turned off, which means turned off for everything.  I should NOT have to edit /etc/fstab to exclude partitions, but since we now do, that should have been addressed as part of the install process, and a GUI provided to the end user.

  B) I attach USB, eSATA, or docked drives that have MULTIPLE partitions, and I do NOT want them automounted when connected.  As before, Karmic attempts to mount them all, with or without authorization depending upon connector type.  And, as noted in Bug 412449, when I click to unmount one, Karmic removes the entire device (again, depending on connector type).  Hopefully, upstream will implement the proposals to separate drive and volume in the GUI.

  C) I attach various SDHC and USB drives with single partitions.  I do want the partition mounted upon connect, *BUT* I may also want to specify mount options, such as the "noatime" option in the /etc/fstab example below.  Are you proposing that I have an entry in fstab for every jump drive?    David made a suggestion about using /etc/fstab with /dev/disk/by-path, but I tried that and observed that given:

   /dev/disk/by-path/pci-0000:15:00.2-part1 /media/SDHC auto defaults,noauto,user,noatime 0 0

Attempting to solve the problem that way creates the following issues:

   1. The mount point (e.g., /media/SDHC) must be specified, rather than vary by partition label
   2. It does not support multiple partitions
   3. Without that entry, NTFS formatted media works; with it, NTFS formatted media will not mount via nautilus

To match media attributes against /etc/fstab requires some seriously whacky udev ju-ju beyond the abilities of most users, and seems highly impractical compared to what would could do with HAL.  So far I have not found out how DeviceKit-disks wants to manage it.  I'm not even sure that DeviceKit wants to handle it, which means that we are losing that aspect of HAL, and need some sort of meta-data policy system to replace it.  udev could do it if we had a means by which udev could tell DeviceKit what attributes to hold on to and use for a device.  But then we get to explain udev to hoi paloi.