trouble authenticating users on v3.22.26a?

[Tkil]

I'm having some difficulties connecting to my mysql server without
using passwords.  It seems that the client doesn't pass along the
username information unless you have used a password.  Example:

As mysql root user:

| mysql> select Host, User, Password, Select_priv from user;
| +------------------+-----------+------------------+-------------+
| | Host             | User      | Password         | Select_priv |
| +------------------+-----------+------------------+-------------+
| | %                | dynweb_ro |                  | N           |
| 
| mysql> select Host, Db, User, Select_priv from db where user like 'dynweb%';
| +------+--------+-----------+-------------+
| | Host | Db     | User      | Select_priv |
| +------+--------+-----------+-------------+
| | %    | dynweb | dynweb_ro | Y           |

As normal user, trying to connect to the read-only userid:

| $ mysql -u dynweb_ro
| mysql> status
| mysql  Ver 9.35 Distrib 3.22.26a, for pc-linux-gnu (i686)
| Current user:           dynweb_ro@localhost
| Server version          3.22.26a-log
| 
| mysql> use dynweb;
| ERROR 1044: Access denied for user: '@localhost' to database 'dynweb'

Note that the username in the error message has no username on it!  So 
far as I understand the MySQL privilege system, this ought to work.
What am I doing wrong?

As a final weirdness, adding the explicit hostname to the user table
allows the connection to go through.  As root, I did:

| mysql> insert into user (Host, User, Password) values ('localhost', 'dynweb_ro', '');
| Query OK, 1 row affected (0.02 sec)
| 
| mysql> flush privileges;
| Query OK, 0 rows affected (0.11 sec)

After these additions, the normal user can now connect:

| $ mysql -u dynweb_ro dynweb
| mysql> show tables;
| +------------------+
| | Tables in dynweb |
| +------------------+
| [...]

So I have a workaround for now, but I thought that "%" in the Host
field of mysql.users was supposed to match any host.  Is there a
hidden "be paranoid" switch that is causing this to not happen?
Either way, the error message is a little confusing (it should
indicate the current user, since "status" at least knows who it is).

Thanks,
Tony