Can one of you look in /usr/share/mysql/charsets and report if there's a
'latin1.xml' file there ?

@ Arkadiusz your akonadi log indicates that the mysql server is being searched
in these directories: /opt/mysql/libexec, /opt/local/lib/mysql5/bin

Where is mysqld installed on your machine ? 

can you paste the output of : `mysql_config`

latin1.xml is there:
-rw-r--r-- 1 root root 9770 02-02 10:12 /usr/share/mysql/charsets/latin1.xml

mysqld is at /usr/sbin/mysqld (and akonadi finds it now since:
arekm     3659  0.0  0.8 226480 31952 ?        Sl   Feb13   1:04
/usr/sbin/mysqld
--defaults-file=/home/users/arekm/.local/share/akonadi//mysql.conf
--datadir=/home/users/arekm/.local/share/akonadi/db_data/
--socket=/home/users/arekm/.local/share/akonadi/db_misc/mysql.socket
)

[arekm@carme-pld ~]$ mysql_config
Usage: /usr/bin/mysql_config [OPTIONS]
Options:
        --cflags         [-I/usr/include/mysql  -DUNIV_LINUX -DUNIV_LINUX]
        --include        [-I/usr/include/mysql]
        --libs           [-L/usr/lib64 -lmysqlclient -lz -lcrypt -lm -lssl
-lcrypto]
        --libs_r         [-L/usr/lib64 -lmysqlclient_r -lz -lpthread -lcrypt
-lm -lpthread -lssl -lcrypto]
        --plugindir      [/usr/lib64/plugin]
        --socket         [/var/lib/mysql/mysql.sock]
        --port           [0]
        --version        [5.1.43]
        --libmysqld-libs [-L/usr/lib64 -lmysqld -ldl -lz -lpthread -lcrypt -lm
-lpthread -lwrap -lrt -lssl -lcrypto]

Thanks.

I just built MySQL 5.1.43 from sources with the following command line:

./configure --prefix=/usr/local --with-plugins=max --enable-shared
--enable-static --with-ssl --without-docs

and wiped the previous akonadi DB to test a first run initialization.
No issue so far:

# which mysqld
/usr/local/libexec/mysqld

# mysqld --version
mysqld  Ver 5.1.43 for pc-linux-gnu on i686 (Source distribution)

# akonadictl status
Akonadi Control: running
Akonadi Server: running
Akonadi Server Search Support: available (backend: Virtuoso)

# ps x |grep mysqld 
21519 ?        Sl     0:01 /usr/local/libexec/mysqld
--defaults-file=/home/krop/.local/share/akonadi//mysql.conf --datadir
/home/krop/.local/share/akonadi/db_data/
--socket=/home/krop/.local/share/akonadi/db_misc/mysql.socket

I'll now try the configure parameters used in the Debian package to check
whether there's a difference or no.

I didn't have more luck with the Debian (SID) options:

# ./configure --prefix=/usr/local --exec-prefix=/usr/local
--libexecdir=/usr/local/sbin --datadir=/usr/local/share
--localstatedir=/var/lib/mysql --includedir=/usr/local/include
--infodir=/usr/local/share/info --mandir=/usr/local/share/man
--build=i486-linux-gnu --host=i486-linux-gnu --with-server-suffix="-1"
--with-comment="(Debian)" --with-system-type="debian-linux-gnu" --enable-shared
--enable-static --enable-thread-safe-client --enable-assembler 
--enable-local-infile --with-pstack --with-fast-mutexes --with-big-tables
--with-unix-socket-path=/var/run/mysqld/mysqld.sock --with-mysqld-user=mysql
--with-libwrap --without-readline --with-ssl --without-docs
--with-extra-charsets=all --with-plugins=max --without-ndbcluster
--with-embedded-server --with-embedded-privilege-control

and Akonadi still works.

# mysql_config 
Usage: /usr/local/bin/mysql_config [OPTIONS]
Options:
        --cflags         [-I/usr/local/include/mysql -DUNIV_LINUX -DUNIV_LINUX]
        --include        [-I/usr/local/include/mysql]
        --libs           [-rdynamic -L/usr/local/lib/mysql -lmysqlclient -lz
-lcrypt -lnsl -lm]
        --libs_r         [-rdynamic -L/usr/local/lib/mysql -lmysqlclient_r -lz
-lpthread -lcrypt -lnsl -lm -lpthread]
        --plugindir      [/usr/local/lib/mysql/plugin]
        --socket         [/var/run/mysqld/mysqld.sock]
        --port           [0]
        --version        [5.1.43]
        --libmysqld-libs [-rdynamic -L/usr/local/lib/mysql -lmysqld -ldl -lz
-lpthread -lcrypt -lnsl -lm -lpthread -lrt]

I applied the Debian patches, still no luck. I'm unable to reproduce the
charset issue.

This is the answer from debian packagers
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=569549

I only needed to downgrade mysql packs

See also downstream report,
https://bugzilla.redhat.com/show_bug.cgi?id=566547

init'ing akonadi with 5.1.43 fails with the error(s) listed here, and that
5.1.42 was last-known good.

is there anything concrete to go on to be able forward on to mysql upstream
that "foo and bar" in 5.1.43 is broken?  Or is it a matter of just being
incompatible somehow?

(Gentoo maintainer of MySQL here)
There IS an entry in the 5.1.43 changelog about charset handling, with code
that was changed between 5.1.42 and 5.1.43:
http://bugs.mysql.com/bug.php?id=45058

I'm not a KDE user myself, so if somebody could try 5.1.43 with the following
patch reverted:
http://lists.mysql.com/commits/87152
That would probably help a lot in tracing. Alternatively try 5.1.42 with the
patch added and see if it breaks where it worked before.

I tried, but it seems only parts of that referenced commit were included in
5.1.43, so would require a bit of surgery to revert.

A patch reverting the charset handling changes in 5.1.43 is now available in
Redhat's Bugzilla:

https://bugzilla.redhat.com/show_bug.cgi?id=566547#c11

This fixed Akonadi with MySQL 5.1.43 under Redhat Linux for the patch author. I
am using MySQL 5.5.1 under FreeBSD. The same patch fixed Akonadi for me as
well. So yes, it is this change to MySQL that makes Akonadi fail. It would seem
like it is not a KDE bug at all.

update:  mysql has been notified of the problem introduced in
http://bugs.mysql.com/45058

(waiting for a bit more detail and evidence before closing->upstream)

Adding the upstream URL. 
I could finally reproduce this bug. Looks like my local 5.1.43 build was
loading libraries from another installed version.

The issue can also be reproduced with with 5.5.1.2 from the unstable opensuse
repo (I then get the same backtrace as the one added to the upstream report).

[akonadiserver] "[
[akonadiserver] 0: akonadiserver(_Z11akBacktracev+0x2e) [0x805a292]
[akonadiserver] 1: akonadiserver [0x805a676]
[akonadiserver] 2: [0xffffe400]
[akonadiserver] 3: /usr/lib/libmysqlclient_r.so.16(my_strcasecmp_8bit+0x2b)
[0xb60fb56b]
[akonadiserver] 4: /usr/lib/libmysqlclient_r.so.16(get_charset_number+0x7a)
[0xb60edefa]
[akonadiserver] 5: /usr/lib/libmysqlclient_r.so.16(get_charset_by_csname+0x6e)
[0xb60eeafe]
[akonadiserver] 6:
/usr/lib/libmysqlclient_r.so.16(mysql_init_character_set+0x82) [0xb6110182]
[akonadiserver] 7: /usr/lib/libmysqlclient_r.so.16(mysql_real_connect+0x2a8)
[0xb61122c8]
[akonadiserver] 8: /usr/lib/qt4/plugins/sqldrivers/libqsqlmysql.so [0xb6252acb]
[akonadiserver] 9: /usr/lib/libQtSql.so.4(_ZN12QSqlDatabase4openEv+0x3f)
[0xb6ea360f]
[akonadiserver] 10:
/kde/inst/akonadi/lib/libakonadiprivate.so.1(_ZN7Akonadi9DataStore4openEv+0x233)
[0xb76f76ab]
[akonadiserver] 11:
/kde/inst/akonadi/lib/libakonadiprivate.so.1(_ZN7Akonadi9DataStoreC1Ev+0xaa)
[0xb76f7104]
[akonadiserver] 12:
/kde/inst/akonadi/lib/libakonadiprivate.so.1(_ZN7Akonadi9DataStore4selfEv+0x3f)
[0xb76f7b23]
[akonadiserver] 13:
/kde/inst/akonadi/lib/libakonadiprivate.so.1(_ZN7Akonadi12CacheCleaner3runEv+0x14)
[0xb77265d8]
[akonadiserver] 14: /usr/lib/libQtCore.so.4 [0xb73caf4f]
[akonadiserver] 15: /lib/libpthread.so.0 [0xb73506e5]
[akonadiserver] 16: /lib/libpthread.so.0 [0xb7350600]
[akonadiserver] ]

Trying to help upstream MySQL guys on this, can somebody please provide the
full argument string that akonadi uses to start the private mysqld instance, as
well as any private my.cnf files with mysqld settings?

mysqld is started like that:

/usr/sbin/mysqld --defaults-file=/home/login/.local/share/akonadi//mysql.conf
--datadir /home/login/.local/share/akonadi/db_data/
--socket=/home/login/.local/share/akonadi/db_misc/mysql.socket

and the mysql.conf used by akonadi 1.3.1 is here: 
http://websvn.kde.org/tags/akonadi/1.3.1/server/src/storage/mysql-global.conf?view=markup

Please see the MySQL-upstream bug for their final patches to solve the issue.

I can confirm in my initial testing that those do the trick.

stick a fork in it!