A couple of things:

Please link to the AUR package (there are more than one).
Please attach your dmesg.
Please make sure the newest udev is installed, and that your initramfs has been regenerated (mkinitrd -p linux).
Please make sure there are no files in /etc/udev/rules.d (i.e. move any custom files out of the way).

I also have problems with my bluetooth mouse (I think it's bluetooth, it's logitech MX Revolution) after the latest udev update. The cursor wanders off as if it has a will of its own.
This may be a different issue, though. If that is the case, please disregard this.

Could you compare lsmod before and after the upgrade? If anything is missing modprobe it manually. Does this help?

After updating udev to version 174, KDE no longer see the bluetooth device but the system itself bluetoth sees it:

#hcitool dev
Devices:
hci0 5C:AC:4C:ED:XX:XX
Also, if bluetooth is on a very long time KDE is loading.
I already rebuilt mkinitcpio.

Perhaps it is a problem with rules in the /var/lib/udev?

A similar problem was:
https://bbs.archlinux.org/viewtopic.php?id=119849

my bluetooth device:
Bus 001 Device 004: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub (part of BCM2046 Bluetooth)

Dmesg:

[ 99.755537] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
[ 99.756778] input: Dell BT Travel Mouse as /devices/pci0000:00/0000:00:1d.1/usb7/7-1/7-1:1.0/bluetooth/hci0/hci0:11/input20
[ 99.756952] generic-bluetooth 0005:046D:B006.0004: input,hidraw2: BLUETOOTH HID v1.24 Mouse [Dell BT Travel Mouse] on 00:22:43:D3:3D:36


Synaptiks:
[link@Hyrule ~]$ synaptiks
[link@Hyrule ~]$ Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/synaptiks/management.py", line 217, in _start_stop_monitors
monitor.start()
File "/usr/lib/python2.7/site-packages/synaptiks/monitors/mouses.py", line 168, in start
self._reset_registry()
File "/usr/lib/python2.7/site-packages/synaptiks/monitors/mouses.py", line 213, in _reset_registry
for device in self.plugged_devices:
File "/usr/lib/python2.7/site-packages/synaptiks/monitors/mouses.py", line 119, in plugged_devices
yield MouseDevice.from_udev(device)
File "/usr/lib/python2.7/site-packages/synaptiks/monitors/mouses.py", line 77, in from_udev
return cls(device['ID_SERIAL'], device.parent['NAME'].strip('"'))
File "/usr/lib/python2.7/site-packages/pyudev/device.py", line 677, in __getitem__
raise KeyError('No such property: {0}'.format(property))
KeyError: u'No such property: ID_SERIAL'

AUR Synaptiks
https://aur.archlinux.org/packages.php?ID=32204

Udev: udev 174-1 x86_64

With udev 172 works fine.

The problem appears to be that udev does not assign a name to the mouse.

Could you verify that there are no stale udev rules?

Do a grep for "SYSFS" and "BUS" in /{etc,lib}/udev/rules.d/*

Don't know if this is of any help, but there are several matches for "BUS" in /lib/udev/rules.d here (but no SYSFS or BUS in lib or etc).

Does that mean my udev rules are stale?

grep -r BUS /lib/udev/rules.d | wc -l
29

@Alexander: Yeah, that's bad. Do you not see any error messages regarding deprecated keys in dmesg? Is udev logging switched on in /etc/udev/udev.conf?

Could you paste the output of "pacman -Qo <name of offending file>" so we know which packages are causing trouble. Also please file bug reports against those packages. That is almost certainly what is causing your issues (see my recent mail to arch-dev-public).

grep -l BUS /lib/udev/rules.d/* | xargs pacman -Qo

gives

60-persistent-alsa.rules is owned by udev 174-1
60-persistent-input.rules is owned by udev 174-1
60-persistent-serial.rules is owned by udev 174-1
60-persistent-storage-tape.rules is owned by udev 174-1
60-persistent-storage.rules is owned by udev 174-1
60-persistent-v4l.rules is owned by udev 174-1
75-net-description.rules is owned by udev 174-1
75-tty-description.rules is owned by udev 174-1
78-sound-card.rules is owned by udev 174-1
80-udisks.rules is owned by udisks 1.0.4-1

Alexander: yikes, that was my bad, I should have been more explicit. Those files look fine. What we are looking for is BUS, ID or SYSFS as keys. I.e. ID= / BUS= / SYSFS=, not when BUS happens to be part of a string. Sorry about that.

No worries. Thanks.

@Alexander: your problem is almost certainly unrelated.
@Miguel: could you paste the output of "udevadm info -a -n /dev/<path to mouse>" with 172 and with 174? Making sure that you don't have any old rule files lying around.

@Tom Yes, did some research, and my problem was something that several others have experienced suddenly with the Logitech MX Performance mouse (cursor wandering). It's unrelated. Thanks.