My original email was initially longer, but I tend to explain my
choices too much so I went with brief this time.
Seems like longer would have been better. Here it is.

On Tue, 20 Aug 2024 at 04:22, Theo de Raadt <deraadt@openbsd.org> wrote:
>
> How do you justify your choice.  Where is the documentation change?

The OpenSSH client allows the @ character in usernames. Therefore the
behaviour of `ssh-add` without my patch is the unexpected thing.

It did not seem appropriate to me to document anything in the source
code itself, I looked at the surrounding functions and obviously at
the function itself to see whether there would be any affected
documentation, which I did not find.

Regarding the man page, I thought about mentioning it. But to be
honest it came as quite the surprise to me that an '@' in the username
was not supported, so especially pointing it out seemed strange to me.
It's not like the man page contains a grammar for valid usernames.
If I'd have to include it I would add "The user name may also contain
@ characters." to the second paragraph under the -h option. Do you see
any merit in that? I don't.

> Your choice means all user-authentication layers are now exposed
> to a login name with a '@' in it. Are they all prepared for that?
> Maybe, but they have not been reviewed.

I'm not sure I understand you correctly, but which user-authentication
layers would specifically be connected to `ssh-add` and the host
constraints that are part of the agent since 8.9? Using an '@' in a
SSH username has been working for as long as I tried. So at least
years. I do not see anything happening with this addition that could
not happen before. I merely brought the behaviour of the `ssh-add`
constraints and thereby the behaviour or SSH agent restrictions in
line with the behaviour of the SSH client.
Where you had to previously use a wildcard user / skip the user, you
now can restrict the public key from being sent for a connection if
the user does not match the expected identity. So instead of widening
or modifying, this seems to strictly narrow down submitted identifiers
and credentials. I can't see the issue here, but might be missing
something about how the value is used.

> Why does your username have a seperation character in it?  Whatever
> you are doing in that subsystem sounds like a serious mistake.  I've
> never heard of this problem before.  It is only you.

Ask Google. Their Cloud Source Repositories use an email address as
the username.