Did you not find the time yet to look at this any further or are you
giving me the silent treatment? What else are you expecting to accept
this patch?

To reiterate it: This is a trivial patch which fixes a clear bug.
According to your initial message you seem to have misunderstood the
scope of the components affected by my change. It simply makes the
behaviour of `ssh-add` match the behaviour of `ssh` in regard to user
names and does not change anything about the exposure of remote
components to the '@'.

Just test the behaviour with any current SSH version (without the
patch applied, obviously) e. g. `ssh -v
user@invalid.invalid@anoncvs.eu.openbsd.org` results in "debug1:
Authenticating to anoncvs.eu.openbsd.org:22 as
'test@invalid.invalid'". Alternatively you can specify "User
user@invalid.invalid" in your ssh_config which works the same.
With the SSH versions I had around I could test this at least back to
OpenSSH 9.2, but I've been relying on the '@' in the user part for
years, so it has probably been supported for a long time.
It is also sending the user name in the same format over the network.

`ssd-add` on the other hand would not recognise it as a user name.

I'm not the one in charge of the system with those names, so there is
hardly anything I can change about the '@' in the user names, but at
some point you seem to have to held the opinion that an '@' in user
names should be valid, which is why it is supported by the ssh
command?
If you look at line 1104ff of the current src/usr.bin/ssh/ssh.c you
will see that the ssh command actually uses `strrchr` in the same
manner.

I could also just apply the patch on my system in perpetuity, but I'm
sure that others who use the constraints will benefit from it. And
there pretty much is no clearer case of a bug which should be fixed.

So all I ask you is to accept the patch to fix this bug, ok?