The link is now in /usr/lib

What's your bug, please? I don't see any description of an actual problem.

I couldn't bind.
Workaround: I done the symbolic link myself

It was present at least at version 162

Excuse me, I still do not understand the problem. Can you please describe precisely what you tried to do and how it failed?

with the use of cmake, the generated link.txt-file spezified (some/most of the time) the needed libraries
as libxyz.so
Most of the libraries have also 3 inodes, ie.
lrwxrwxrwx 1 root root 18 28. Mai 2010 libshadow.so -> libshadow.so.0.0.0
lrwxrwxrwx 1 root root 18 28. Mai 2010 libshadow.so.0 -> libshadow.so.0.0.0
-rwxr-xr-x 1 root root 62138 28. Mai 2010 libshadow.so.0.0.0

The libudev.so at version 164 has only 2 inodes.

The ld-command cannot work.

You still did not say what doesn't work, please provide an actual example of what is wrong, not some abstract claims I cannot verify.

ld works quite fine btw:

$ cat > "test.c" << "EOF"
> int main() {
> return 0;
> }
> EOF
$ gcc -o test test.c -Wall -ludev
$ ldd test
linux-vdso.so.1 => (0x00007fffcfff9000)
libudev.so.0 => /lib/libudev.so.0 (0x00007feb366be000)
libc.so.6 => /lib/libc.so.6 (0x00007feb36361000)
/lib/ld-linux-x86-64.so.2 (0x00007feb368cb000)
$

You are right. But It is not what I am pointing to. I try to be "not abstract".
I found a difference between the versions 163-1-x86_64 and 164-3-x86_64, as one can see below:
$ pacman -Q -l -p /var/cache/pacman/pkg/udev-163-1-x86_64.pkg.tar.xz | grep libudev.so
udev /lib/libudev.so
udev /lib/libudev.so.0
udev /lib/libudev.so.0.9.1
$ pacman -Q -l -p /var/cache/pacman/pkg/udev-164-3-x86_64.pkg.tar.xz | grep libudev.so
udev /lib/libudev.so.0
udev /lib/libudev.so.0.9.3
udev /usr/lib/libudev.so

The file libudev.so has changes the directory from /lib to /usr/lib, as written at the first comment
Is it an packaging error or a new feature, beginning at the version 164-3?

I know that, but you still fail to tell me why this is a bug.

This was probably caused by us, changing configure from --prefix=/ to --prefix=/usr, if I read the udev Makefile right. This is intended behaviour by upstream udev developers.

OK!
I used cmake to prepare kdelibs.
The next day I made a pacman -Su
I got without take care of it, the version 164-3 of udev
Tried to "make" and got the ld-problem

If this was "really" intended, I hope that some people had a good use of that change.

I found it not very pretty.
If cmake generate such new files, all the .o and libraries will needed to be build at new.
It takes lot of time for a so little change! I don't see now the advantage of the change,
my view might be to small.
Thanks for helping.