You kind of do know who they are, the first message was signed by the the first key, so you know that key is associated with that message and the author who sent that message. You don't know their name, but you know that this author, whatever their name may be, has control of that key pair.
As an end user, you see that the first message and second message were signed with different key pairs. Since you know that the first key is controlled by the author of the first message, you use a little bit of logic to deduce that the second message must not be authored by them, because it was not signed by the key pair that signed the first message.
So PGP did do it's job here IMO. The end user sees that there are two different authors here, which is what it was meant to do!
>No way for me to tell which one of those is the actual you, because I don't know who you are.
You don't really need to know this oftentimes, you just need to know that author A is in control of key pair A, and any messages that aren't signed with key pair A must not be authored by author A.
An example of this is trust on first use. You find some python library that colors terminal output, and it happens to be signed with key pair A. Going forward if you check the signature of the release artifacts, you know that it was authored by the same person that authored the original library you used, even if you don't actually know who they are.
Another example of this is TLS certificates. When creating a TLS certificate for your domain name, there is no cryptographic guarantee that the person who paid for the domain name is in control of the machine that is used to create the certificates associated with that domain name.
The only guarantee that is made, is that the person in control of the machine used to create the certs is the only person who has access to the private key material. So in practice this only proves that the machine you connect to when going to $url is controlled by the person who controlled the machine used to create the certs.
We can imagine person A buying $domain. They setup their DNS records to point to an IP address. If the DNS servers used by lets encrypt (for example) lie about the record, it is possible that an untrusted party is able to create a certificate for person A's $domain.