This is a new udev 057 feature. I can confirm this and have an answer why there are "problems" with permission settings.

I included links is in this forum thread:
http://bbs.archlinux.org/viewtopic.php?t=12071

This not only affects custom rule settings but standard rules too. For example I have a cd recorder as /dev/hdc. I have a custom rule for /dev/hdc in 00.udev.rules file with GROUP="users". It also adds my custom symlinks (and they work fine - this means the rules are properly mixed). Udev ignores group setting and reads it from the standard arch udev.rules. But it's not optical :-) Instead it gives the permission for group "disk":

ls -l /dev/hdc
brw-rw---- 1 root disk 22, 0 2005-04-29 17:43 /dev/hdc

probably because SUBSYSTEM rule is not executed immidiately but as the last one (coincidence).

All of this means that standard arch udev rules probably need rewriting (maybe not only adding OPTIONS="last_rule").

my groups are ok but i don't use custom rules only default rules

So do things work as expected if custom rules are accompanied with the OPTIONS="last_rule" option?

they did work

More or less. You need to copy other rules (e.g. creating symlinks for cdroms) to the custom ruleset file and place them _before_ the last rule. In my case I had to copy the following rule to my 00.udev.rules:

BUS="ide", KERNEL="hd[a-z]", PROGRAM="/etc/udev/cdsymlinks.sh %k", SYMLINK="%c{1} %c{2} %c{3} %c{4} %c{5} %c{6}"

to have /dev/cdroms/cdrom0 created.
Of course it's user's decision if he wants these symlinks or not.

But it seems that with current standard rules you can have some problems too.

An example is the wrong GROUP permission for my /dev/hdc burner.
If you don't have custom rules for /dev/hdc (or if you have a custom rule but without OPTIONS="last_rule") the following rules from standard udev.rules are applied (at least):

SUBSYSTEM="block", GROUP="disk"

BUS="ide", KERNEL="hd[a-z]", PROGRAM="/etc/udev/cdsymlinks.sh %k", SYMLINK="%c{1} %c{2} %c{3} %c{4} %c{5} %c{6}"

BUS="ide", KERNEL="hd[a-z]", SYSFS{removable}="1", PROGRAM="/bin/cat /proc/ide/%k/media", RESULT="cdrom*", NAME="%k", GROUP="optical"

The change in 057 version makes first rule GROUP setting overwrite the third rule GROUP setting becasue SUBSYSTEM is applied as the last rule (nice exception :-) ) _and_ the third rule does not have OPTIONS="last_rule".

I have no idea if this is a bug or a feature in this udev version but I just described how it worked on my system.

I enclose the output of:
udevinfo -a -p `udevinfo -q path -n /dev/hdc`

udevinfo starts with the device the node belongs to and then walks up the
device chain, to print for every device found, all possibly useful attributes
in the udev key format.
Only attributes within one device section may be used together in one rule,
to match the device for which the node will be created.

device '/sys/block/hdc' has major:minor 22:0
looking at class device '/sys/block/hdc':
SUBSYSTEM=="block"
SYSFS{dev}=="22:0"
SYSFS{range}=="1"
SYSFS{removable}=="1"
SYSFS{size}=="8388604"
SYSFS{stat}==" 0 0 0 0 0 0 0 0 0 0 0"

follow the "device"-link to the physical device:
looking at the device chain at '/sys/devices/pci0000:00/0000:00:1f.1/ide1/1.0':
BUS=="ide"
ID=="1.0"
DRIVER=="unknown"
SYSFS{detach_state}=="0"

looking at the device chain at '/sys/devices/pci0000:00/0000:00:1f.1/ide1':
BUS==""
ID=="ide1"
DRIVER=="unknown"
SYSFS{detach_state}=="0"

looking at the device chain at '/sys/devices/pci0000:00/0000:00:1f.1':
BUS=="pci"
ID=="0000:00:1f.1"
DRIVER=="PIIX_IDE"
SYSFS{class}=="0x01018a"
SYSFS{detach_state}=="0"
SYSFS{device}=="0x24cb"
SYSFS{irq}=="18"
SYSFS{local_cpus}=="1"
SYSFS{subsystem_device}=="0x8089"
SYSFS{subsystem_vendor}=="0x1043"
SYSFS{vendor}=="0x8086"

looking at the device chain at '/sys/devices/pci0000:00':
BUS==""
ID=="pci0000:00"
DRIVER=="unknown"
SYSFS{detach_state}=="0"