Let's do a small experiment:

root# dpkg -i dummy_1_all.deb
Selecting previously deselected package dummy.
(Reading database ... 288646 files and directories currently installed.)
Unpacking dummy (from dummy_1_all.deb) ...
Setting up dummy (1) ...
# No postinst, no preinst, nothing
root# cat /var/lib/dpkg/info/dummy.conffiles
/etc/dummy/test1
root# ls -l /etc/dummy/test1
-rw-r--r-- 1 root root 9 Mar 18 01:01 /etc/dummy/test1
root# cat /etc/dummy/test1
coshoopu
root# echo "I am a bug" > /tmp/a
root# rm /etc/dummy/test1; ln -s /tmp/a /etc/dummy/test1; cat /etc/dummy/test1
I am a bug
root# ls -l /etc/dummy/test1
lrwxrwxrwx 1 root root 6 Mar 19 22:24 /etc/dummy/test1 -> /tmp/a
root# dpkg -P dummy
(Reading database ... 288643 files and directories currently installed.)
Removing dummy ...
Purging configuration files for dummy ...
dpkg: warning: while removing dummy, directory '/etc/dummy' not empty so not removed.
root# ls -l /etc/dummy/
total 0
lrwxrwxrwx 1 root root 6 Mar 19 22:24 test1 -> /tmp/a
root# ls -l /tmp/a
ls: cannot access /tmp/a: No such file or directory

######################################
The target of the symlink was deleted, not the symlink itself.
This can lead to unexpected user data (I deem this rather unimportant
as it is a cornercase) and leaves garbage behind.

I just noticed this behavior too, and I find it astonishing and
worrisome.  I sometimes manually replace a conf file with a symlink
to a file in my own private config directory (example: /etc/foo ->
/mydir/foo).  I always assumed that dpkg remove --purge would remove
the conf file /etc/foo and not touch /mydir/foo, but in fact just the
opposite happens: it removes /mydir/foo and leaves the dangling symlink
/etc/foo. /mydir is mine, not part of any package, so the package system
should not be touching it.

Was there some motivation for this behavior?  It's caused by a call to
conffderef() in remove.c, but what for?

AMC